Patrón de Inicio de sesión REST API

Question

Patrón de Inicio de sesión REST API

Estoy creando una api REST, siguiendo de cerca las sugerencias de apigee, usando sustantivos no verbos, versión de api horneada en la url, dos rutas de api por colección, uso de ELIMINACIÓN de GET POST PUT, etc.

Estoy trabajando en el sistema de inicio de sesión, pero no estoy seguro de la forma correcta de REST para iniciar sesión. No estoy trabajando en la seguridad en este punto, solo el patrón de inicio de sesión o flujo. (Más tarde añadiremos 2 paso OAuth, con un HMAC, etc.)

Posibles opciones

Un POST para algo como https://api...com/v1/login.json
A PONER algo como https://api...com/v1/users.json
Algo de lo que no he pensado...

¿Cuál es el estilo REST adecuado para iniciar sesión en los usuarios?

162

design-patterns rest api

Author: Scott Roepnack, 2012-12-17

Source

3 answers

TL; DR El inicio de sesión para cada solicitud no es un componente necesario para implementar la seguridad de la API, la autenticación sí lo es.

Es difícil responder a su pregunta sobre el inicio de sesión sin hablar de la seguridad en general. Con algunos esquemas de autenticación, no hay un inicio de sesión tradicional.

REST no dicta ninguna regla de seguridad, pero la implementación más común en la práctica es OAuth con autenticación de 3 vías (como mencionaste en tu pregunta). No hay log-in per se, al menos no con cada solicitud de API. Con la autenticación de 3 vías, solo usa tokens.

El usuario aprueba el cliente API y otorga permiso para realizar solicitudes en forma de token de larga duración
El cliente Api obtiene un token de corta duración mediante el uso del token de larga duración.
El cliente Api envía el token de corta duración con cada solicitud.

Este esquema le da al usuario la opción de revocar el acceso en cualquier momento. Practicamente todas las API RESTful disponibles públicamente que he visto usar OAuth para implementar este.

Simplemente no creo que deba enmarcar su problema (y pregunta) en términos de inicio de sesión, sino pensar en asegurar la API en general.

Para obtener más información sobre la autenticación de las API REST en general, puede consultar los siguientes recursos:

39

Author: Slavo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 11:54:57

Una gran parte de la filosofía REST es explotar tantas características estándar del protocolo HTTP como sea posible al diseñar su API. Aplicando esa filosofía a la autenticación, el cliente y el servidor utilizarían características de autenticación HTTP estándar en la API.

Las pantallas de inicio de sesión son excelentes para casos de uso de usuarios humanos: visite una pantalla de inicio de sesión, proporcione un usuario/contraseña, establezca una cookie, el cliente proporciona esa cookie en todas las solicitudes futuras. No se puede esperar que los humanos que usan navegadores web proporcionen un id de usuario y contraseña con cada solicitud HTTP individual.

Pero para una API REST, una pantalla de inicio de sesión y cookies de sesión no son estrictamente necesarias, ya que cada solicitud puede incluir credenciales sin afectar a un usuario humano; y si el cliente no coopera en cualquier momento, se puede dar una respuesta "no autorizada" 401. RFC 2617 describe el soporte de autenticación en HTTP.

TLS (HTTPS) también sería una opción, y permitiría la autenticación del cliente al servidor (y viceversa) en cada solicitud mediante la verificación de la clave pública de la otra parte. Además, esto asegura el canal para un bono. Por supuesto, un intercambio de par de claves antes de la comunicación es necesario para hacer esto. (Tenga en cuenta que esto se trata específicamente de identificar/autenticar al usuario con TLS. Asegurar el canal usando TLS / Diffie-Hellman siempre es una buena idea, incluso si no identificas al usuario por su clave pública.)

Un ejemplo: supongamos que un token OAuth es su inicio de sesión completo credencial. Una vez que el cliente tiene el token OAuth, se puede proporcionar como id de usuario en la autenticación HTTP estándar con cada solicitud. El servidor podría verificar el token en el primer uso y almacenar en caché el resultado de la verificación con un tiempo de vida que se renueva con cada solicitud. Cualquier solicitud que requiera autenticación devuelve 401 si no se proporciona.

22

Author: wberry,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-12-19 17:51:26

score 119 · Accepted Answer

El diseño basado en Principios de la Arquitectura Web Moderna por Roy T. Fielding y Richard N. Taylor, es decir, la secuencia de obras de toda la terminología de REST, contiene la definición de la interacción cliente-servidor:

Todas las interacciones de REST son apátridas. Es decir, cada uno la solicitud contiene toda la información necesaria para que un conector entienda el solicitud, independiente de las solicitudes que la hayan precedido.

Esta restricción cumple cuatro funciones, 1ª y 3ª es importante en este caso particular:

1st : it elimina cualquier necesidad de que los conectores conserven el estado de la aplicación entre solicitudes , reduciendo así el consumo de recursos físicos y mejorando la escalabilidad;
3rd : permite a un intermediario ver y entender una solicitud de forma aislada, que puede ser necesario cuando los servicios son dinámicamente reordenado;

Y ahora volvamos a su caso de seguridad. Cada solicitud debe contener toda la información requerida,y la autorización / autenticación no es una excepción. Cómo lograr esto? Literalmente envíe toda la información requerida a través de cables con cada solicitud.

Uno de los ejemplos de cómo arquear esto es código de autenticación de mensajes basado en hash o HMAC. En la práctica, esto significa agregar un código hash del mensaje actual a cada solicitud. Hash código calculado mediante la función hash criptográfica en combinación con una clave criptográfica secreta . La función hash criptográficaes predefinida o parte de la concepción REST de código bajo demanda (por ejemplo, JavaScript). La clave criptográfica secreta debe ser proporcionada por el servidor al cliente como recurso, y el cliente la usa para calcular el código hash para cada solicitud.

Hay muchos ejemplos de implementaciones de HMAC , pero me gustaría que pagaras atención a los tres siguientes:

Cómo funciona en la práctica

Si el cliente conoce la clave secreta, entonces está listo para operar con recursos. De lo contrario, será redirigido temporalmente (código de estado 307 Redireccionamiento temporal) para autorizar y obtener la clave secreta, y luego redirigido de nuevo al recurso original. En este caso no hay necesidad de saber de antemano (es decir, hardcode en algún lugar) cuál es la URL para autorizar al cliente, y es posible ajustar este esquema con el tiempo.

Espero que esto le ayude a encontrar la solución adecuada!