que ejemplo diseño api rest design-patterns

ejemplo - api rest que es



Patrón de inicio de sesión API REST (3)

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. Al aplicar 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 ideales para casos de uso de usuarios humanos: visitar una pantalla de inicio de sesión, proporcionar usuario / contraseña, establecer una cookie, el cliente proporciona esa cookie en todas las solicitudes futuras. No se puede esperar que los humanos que usan navegadores web proporcionen una identificación 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 al verificar la clave pública de la otra parte. Además, esto asegura el canal para una bonificación. Por supuesto, es necesario un intercambio de pares de claves antes de la comunicación para hacer esto. (Tenga en cuenta que se trata específicamente de identificar / autenticar al usuario con TLS. Asegurar el canal mediante TLS / Diffie-Hellman siempre es una buena idea, incluso si no identifica al usuario por su clave pública).

Un ejemplo: supongamos que un token de OAuth son sus credenciales de inicio de sesión completas. Una vez que el cliente tiene el token de OAuth, se puede proporcionar como identificación 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 del control con un tiempo de vida que se renueva con cada solicitud. Cualquier solicitud que requiera autenticación devuelve 401 si no se proporciona.

Estoy creando una API REST, siguiendo de cerca las sugerencias de la especie, usando sustantivos, no verbos, versión de API horneada en la url, dos rutas de API por colección, GET POST PUT DELETE uso, etc.

Estoy trabajando en el sistema de inicio de sesión, pero no estoy seguro de la forma adecuada de REST para iniciar sesión en los usuarios. No estoy trabajando en seguridad en este momento, solo el patrón o flujo de inicio de sesión. (Más adelante agregaremos 2 pasos oAuth, con HMAC, etc.)

Posibles opciones

  • Un POST para algo como https://api...com/v1/login.json
  • UN PUT para algo como https://api...com/v1/users.json
  • Algo que no he pensado ...

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

El diseño basado en principios de la arquitectura web moderna por Roy T. Fielding y Richard N. Taylor , es decir, la secuencia de trabajos de toda la terminología REST proviene de, contiene la definición de interacción cliente-servidor:

Todas las interacciones REST son apátridas . Es decir, cada solicitud contiene toda la información necesaria para que un conector comprenda la solicitud, independientemente de cualquier solicitud que pueda haberle precedido .

Esta restricción cumple cuatro funciones, la primera y la tercera es importante en este caso particular:

  • Primero : elimina la necesidad de que los conectores retienen el estado de la aplicación entre las solicitudes , reduciendo así el consumo de recursos físicos y mejorando la escalabilidad;
  • 3º : permite a un intermediario ver y comprender una solicitud de forma aislada , lo que puede ser necesario cuando los servicios se reorganizan dinámicamente;

Y ahora regresemos 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 archivar esto es el código de autenticación de mensajes basado en hash o HMAC . En la práctica, esto significa agregar un código hash de mensaje actual a cada solicitud. Código hash calculado por función hash criptográfica en combinación con una clave criptográfica secreta . La función hash criptográfica está predefinida o es parte de la concepción REST de código bajo demanda (por ejemplo, JavaScript). El servidor debe proporcionar la clave criptográfica secreta 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 preste atención a los siguientes tres:

Cómo funciona en la práctica

Si el cliente conoce la clave secreta, está lista para operar con recursos. De lo contrario, se redirigirá temporalmente (código de estado 307 redireccionamiento temporal) para autorizar y obtener la clave secreta, y luego se redirigirá de regreso al recurso original. En este caso, no es necesario saber de antemano (es decir, hardcode en alguna parte) cuál es la URL para autorizar al cliente , y es posible ajustar este esquema con el tiempo.

Espero que esto te ayude a encontrar la solución adecuada.

TL; DR El inicio de sesión para cada solicitud no es un componente obligatorio 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 seguridad en general. Con algunos esquemas de autenticación, no hay inicio de sesión tradicional.

REST no impone 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 lo mencionó en su pregunta). No hay inicio de sesión per se, al menos no con cada solicitud de API. Con la autenticación de 3 vías, solo usa tokens.

  1. El usuario aprueba el cliente API y otorga permiso para realizar solicitudes en forma de un token de larga vida
  2. El cliente Api obtiene un token de vida corta usando el de larga duración.
  3. El cliente Api envía el token efímero con cada solicitud.

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

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

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