web-services - probar - rest api tutorial español

Asegurar API REST sin reinventar la rueda

Question

Cuando se diseña API REST, ¿es común autenticar primero a un usuario?

El caso de uso típico que estoy buscando es:

• El usuario quiere obtener datos. ¡Seguro que nos gusta compartir! ¡Obtenga una clave API pública y lea!
• El usuario quiere almacenar / actualizar datos ... ¡Espera! ¿Quién eres tú? ¿Puedes hacer esto?

Me gustaría construirlo una vez y permitir, por ejemplo, una aplicación web, una aplicación de Android o una aplicación de iPhone para usarlo.

Una API REST parece ser una opción lógica con requisitos como este

Para ilustrar mi pregunta, usaré un ejemplo simple.

Tengo un elemento en una base de datos, que tiene un atributo de calificación (número entero de 1 a 5).

Si entiendo REST correctamente, implementaría una solicitud GET usando el lenguaje de mi elección que devuelva csv, xml o json de la siguiente manera:

http://example.com/product/getrating/{id}/

Digamos que elegimos JSON, volvemos:

{
"id": "1",
"name": "widget1",
"attributes": { "rating": {"type":"int", "value":4} }
}

Esto está bien para API públicas. Yo entiendo esa parte.

Donde tengo toneladas de preguntas es ¿cómo combino esto con un modelo de seguridad? Estoy acostumbrado a la seguridad de aplicaciones web donde tengo un estado de sesión que identifica a mi usuario en todo momento para poder controlar lo que pueden hacer sin importar lo que decidan enviarme. Según tengo entendido, esto no es RESTful, por lo que sería una mala solución en este caso.

Trataré de usar otro ejemplo usando el mismo artículo / calificación.

Si el usuario "JOE" quiere agregar una calificación a un elemento

Esto podría hacerse usando:

http://example.com/product/addrating/{id}/{givenRating}/

En este punto, quiero almacenar los datos que dicen que "JOE" le dio al producto {id} una calificación de {givenRating}.

Pregunta: ¿Cómo sé que la solicitud vino de "JOE" y no de "BOB"?

Además, ¿y si fuera por datos más sensibles como el número de teléfono de un usuario?

Lo que tengo hasta ahora es:

1) Use la característica incorporada de HTTP para autenticarse en cada solicitud, ya sea HTTP o HTTPS.

Esto significa que cada solicitud ahora toma la forma de:

https://joe:[email protected]/product/addrating/{id}/{givenRating}/

2) Use un enfoque como el S3 de Amazon con clave privada y pública: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

3) Use una cookie de todos modos y rompa la parte sin estado de REST.

El segundo enfoque me parece mejor, pero me pregunto si realmente tengo que reinventar todo esto. Hashing, almacenamiento, generación de claves, etc. todo por mi cuenta?

Esto se parece mucho a usar la sesión en una aplicación web típica y reescribir la pila entera usted mismo, lo que generalmente significa "Lo estás haciendo mal", especialmente cuando se trata de seguridad.

EDITAR: Creo que debería haber mencionado OAuth también.

Answer 1

No se preocupe por ser "RESTful", preocúpese por la seguridad. Así es como lo hago:

Paso 1: el usuario acceda al servicio de autenticación con credenciales.

Paso 2: Si las credenciales se retiran, envíe una huella digital, una identificación de sesión, etc., y colóquelas en la memoria compartida para recuperarlas más tarde o utilice una base de datos si no le importa agregar algunos milisegundos al tiempo de respuesta de su servicio web. .

Paso 3: Agregue una llamada de punto de entrada a la parte superior de cada script de servicio web que valida la huella digital y la identificación de sesión para cada solicitud de servicio web.

Paso 4: Si la identificación de la huella dactilar y la sesión no son válidas o han agotado el tiempo de espera, redirigir a la autenticación.

LEE ESTO:

Autenticación RESTful

Answer 2

Editar 3 años después

Estoy totalmente de acuerdo con Evert, uso OAuth2 con HTTPS y no reinventar la rueda. :-)

Mediante API REST más simples, no destinadas a clientes de terceros, las tokens web JSON también pueden ser buenas.

Versión previa

Use una cookie de todos modos y rompa la parte sin estado de REST.

No use sesiones, con sesiones su servicio REST no será bien escalable ... Aquí hay 2 estados: estado de la aplicación (o estado del cliente o sesión s) y estado del recurso. El estado de la aplicación contiene los datos de la sesión y el cliente REST lo mantiene. El estado del recurso contiene las propiedades y relaciones del recurso y es mantenido por el servicio REST. Puede decidir muy fácilmente si una variable en particular es parte del estado de la aplicación o del estado del recurso. Si la cantidad de datos aumenta con el número de sesiones activas, entonces pertenece al estado de la aplicación. Entonces, por ejemplo, la identidad del usuario por la sesión actual pertenece al estado de la aplicación, pero la lista de usuarios o permisos de usuario pertenece al estado del recurso.

Entonces, el cliente REST debe almacenar los factores de identificación y enviarlos con cada solicitud. No confunda el cliente REST con el cliente HTTP. Ellos no son los mismos. El cliente REST también puede estar del lado del servidor si usa curl, o puede crear, por ejemplo, una cookie HTTP solo del lado del servidor que puede compartir con el servicio REST a través de CORS. Lo único importante es que el servicio REST debe autenticarse en cada solicitud, por lo que debe enviar las credenciales (nombre de usuario, contraseña) con cada solicitud.

• Si escribe un cliente REST del lado del cliente, esto se puede hacer con autenticación SSL + HTTP. En ese caso, puede crear una caché de credentials -> (identity, permissions) en el servidor para acelerar la autenticación. Tenga en cuenta que si borra esa caché y los usuarios envían la misma solicitud, obtendrán la misma respuesta, pero tardará un poco más. Puede comparar esto con las sesiones: si borra el almacén de sesiones, los usuarios obtendrán un status: 401 unauthorized respuesta status: 401 unauthorized ...
• Si escribe un cliente REST del lado del servidor y envía factores de identificación al servicio REST mediante curl, entonces tiene 2 opciones. También puede usar http auth o puede usar un administrador de sesión en su cliente REST pero no en el servicio REST.
• Si alguien que no es de confianza escribe su cliente REST, entonces debe escribir una aplicación para autenticar a los usuarios y darles la disponibilidad para decidir si desean otorgar permisos a diferentes clientes o no. Oauth es una solución ya existente para eso. Oauth1 es más seguro, oauth2 es menos seguro pero más simple, y creo que hay muchas otras soluciones para este problema ... No tiene que reinventar esto. Existen soluciones completas de autenticación y autorización que usan oauth, por ejemplo: el servidor de identidad wso .

Las cookies no son necesariamente malas. Puede usarlos de forma RESTANTE hasta que tengan el estado del cliente y el servicio solo tenga el estado del recurso. Por ejemplo, puede almacenar el carro o la configuración de paginación preferida en las cookies ...

Answer 3

Editar 5 años después

¡Usa OAuth2!

Versión previa

No, no hay absolutamente ninguna necesidad de usar una cookie. No es ni la mitad de seguro que HTTP Digest, OAuth o AWS de Amazon (que no es difícil de copiar).

La forma en que debes mirar una cookie es que es un token de autenticación tanto como Basic / Digest / OAuth / lo que sea, pero menos apropiado.

Sin embargo, no creo que el uso de una cookie vaya en contra de los principios RESTful per se , siempre y cuando el contenido de la cookie de sesión no influya en el contenido del recurso que está devolviendo desde el servidor.

Las cookies son malvadas, deja de usarlas.