session - example - rest basic




¿Las sesiones realmente violan RESTfulness? (4)

¿El uso de sesiones en una API RESTful realmente está violando a RESTfulness? He visto muchas opiniones en cualquier dirección, pero no estoy convencido de que las sesiones sean RESTless . Desde mi punto de vista:

  • la autenticación no está prohibida para RESTfulness (de lo contrario habría poco uso en los servicios RESTful)
  • la autenticación se realiza mediante el envío de un token de autenticación en la solicitud, generalmente el encabezado
  • este token de autenticación debe obtenerse de alguna manera y puede ser revocado, en cuyo caso debe renovarse
  • el token de autenticación debe ser validado por el servidor (de lo contrario no sería autenticación)

Entonces, ¿cómo las sesiones violan esto?

  • del lado del cliente, las sesiones se realizan utilizando cookies.
  • Las cookies son simplemente un encabezado HTTP adicional
  • Una cookie de sesión se puede obtener y revocar en cualquier momento.
  • Las cookies de sesión pueden tener un tiempo de vida infinito si es necesario.
  • el id de sesión (token de autenticación) se valida del lado del servidor

Como tal, para el cliente, una cookie de sesión es exactamente igual a cualquier otro mecanismo de autenticación basado en encabezado HTTP, excepto que utiliza el encabezado de Cookie lugar de la Authorization o algún otro encabezado propietario. Si no hubiera una sesión adjunta al lado del servidor con valor de cookie, ¿por qué eso haría una diferencia? La implementación del lado del servidor no necesita preocupar al cliente siempre que el servidor se comporte de forma REST. Como tales, las cookies por sí mismas no deberían tener una API RESTless , y las sesiones son simplemente cookies para el cliente.

¿Están mis suposiciones equivocadas? ¿Qué hace que las cookies de sesión sean RESTless ?


  1. Las sesiones no son RESTless
  2. ¿Quiere decir que el servicio REST solo para uso de http o me equivoco un poco? ¡La sesión basada en cookies se debe utilizar solo para los servicios basados ​​en http (!) Propios! (Podría ser un problema trabajar con cookies, por ejemplo, desde Mobile / Console / Desktop / etc.)
  3. Si proporciona un servicio REST para los desarrolladores de terceros, nunca use una sesión basada en cookies, use tokens para evitar los problemas de seguridad.

En primer lugar, REST no es una religión y no debe abordarse como tal. Si bien los servicios RESTful ofrecen ventajas, solo debe seguir los principios de REST en la medida en que tengan sentido para su aplicación.

Dicho esto, la autenticación y el estado del lado del cliente no violan los principios REST. Mientras que REST requiere que las transiciones de estado sean sin estado, esto se refiere al servidor en sí. En el corazón, todo REST es sobre documentos. La idea detrás de la apatridia es que el SERVIDOR es apátrida, no los clientes. Cualquier cliente que emita una solicitud idéntica (los mismos encabezados, cookies, URI, etc.) debe ser llevado al mismo lugar en la aplicación. Si el sitio web almacenaba la ubicación actual del usuario y la navegación administrada al actualizar esta variable de navegación del lado del servidor, se violaría REST. Otro cliente con información de solicitud idéntica se llevaría a una ubicación diferente dependiendo del estado del lado del servidor.

Los servicios web de Google son un ejemplo fantástico de un sistema RESTful. Requieren un encabezado de autenticación con la clave de autenticación del usuario para pasar cada solicitud. Esto viola ligeramente los principios de REST, porque el servidor está rastreando el estado de la clave de autenticación. El estado de esta clave debe mantenerse y tiene algún tipo de fecha / hora de caducidad después de la cual ya no otorga acceso. Sin embargo, como mencioné en la parte superior de mi publicación, se deben hacer sacrificios para permitir que una aplicación realmente funcione. Dicho esto, los tokens de autenticación deben almacenarse de una manera que permita a todos los posibles clientes continuar otorgando acceso durante sus tiempos válidos. Si un servidor está administrando el estado de la clave de autenticación hasta el punto de que otro servidor con carga equilibrada no puede asumir el cumplimiento de las solicitudes basadas en esa clave, usted ha comenzado a violar realmente los principios de REST. Los servicios de Google aseguran que, en cualquier momento, puede tomar un token de autenticación que estaba usando en su teléfono contra el servidor de equilibrio de carga A y golpear el servidor de equilibrio de carga B desde su escritorio y aún tener acceso al sistema y ser dirigido a los mismos recursos si Las peticiones eran idénticas.

Todo se reduce a que es necesario asegurarse de que sus tokens de autenticación se validen contra un almacén de respaldo de algún tipo (base de datos, caché, lo que sea) para garantizar que conserva la mayor cantidad posible de propiedades REST.

Espero que todo eso tenga sentido. También debe consultar la sección Restricciones del artículo de wikipedia si aún no lo ha hecho. Es particularmente esclarecedor con respecto a lo que los principios de REST están defendiendo y por qué.


La transacción HTTP, la autenticación de acceso básico, no es adecuada para RBAC, porque la autenticación de acceso básica utiliza el nombre de usuario cifrado: contraseña cada vez que se identifica, mientras que lo que se necesita en RBAC es el rol que el usuario desea usar para una llamada específica. RBAC no valida los permisos en el nombre de usuario, sino en los roles.

Se podría tratar de concatenar de esta manera: usernameRole: password, pero esto es una mala práctica, y también es ineficiente porque cuando un usuario tiene más roles, el motor de autenticación debería probar todos los roles en concatenación, y eso es lo que hace cada llamada nuevamente. Esto destruiría una de las mayores ventajas técnicas de RBAC, a saber, una prueba de autorización muy rápida.

Por lo tanto, ese problema no se puede resolver utilizando la autenticación de acceso básica.

Para resolver este problema, el mantenimiento de la sesión es necesario, y eso parece, de acuerdo con algunas respuestas, en contradicción con REST.

Eso es lo que me gusta de la respuesta de que REST no debe ser tratado como una religión. En casos de negocios complejos, en salud, por ejemplo, RBAC es absolutamente común y necesario. Y sería una pena que no se les permitiera usar REST porque todos los diseñadores de herramientas REST tratarían a REST como una religión.

Para mí no hay muchas maneras de mantener una sesión a través de HTTP. Se pueden usar cookies, con un ID de sesión o un encabezado con un Id. De sesión.

Si alguien tiene otra idea, me alegrará escucharla.


Las cookies no son para la autenticación. ¿Por qué reinventar una rueda? HTTP tiene mecanismos de autenticación bien diseñados. Si utilizamos cookies, solo utilizamos HTTP como protocolo de transporte, por lo tanto, necesitamos crear nuestro propio sistema de señalización, por ejemplo, para informar a los usuarios que proporcionaron una autenticación incorrecta (usar HTTP 401 sería incorrecto, ya que probablemente no lo haríamos). suministre Www-Authenticate a un cliente, ya que las especificaciones HTTP requieren :)). También se debe tener en cuenta que Set-Cookie es solo una recomendación para el cliente. Su contenido puede o no guardarse (por ejemplo, si las cookies están deshabilitadas), mientras que el encabezado de Authorization se envía automáticamente en cada solicitud.

Otro punto es que, para obtener una cookie de autorización, ¿es probable que primero desee proporcionar sus credenciales en algún lugar? Si es así, ¿no sería RESTless? Ejemplo simple:

  • Intenta GET /a sin cookie
  • Obtienes una solicitud de autorización de alguna manera
  • Vas y autorizas de alguna manera como POST /auth
  • Obtienes Set-Cookie
  • Intenta GET /a con cookie. Pero, ¿se comporta GET /a idempotentemente en este caso?

Para resumir, creo que si accedemos a algún recurso y necesitamos autenticarlo, debemos autenticarlo en ese mismo recurso , no en ningún otro lugar.





restful-authentication