Estoy específicamente interesado en cómo los usuarios realizan operaciones autorizadas / autenticadas en una API web.
¿Las cookies de autenticación son compatibles con la filosofía REST y por qué?
Estoy específicamente interesado en cómo los usuarios realizan operaciones autorizadas / autenticadas en una API web.
¿Las cookies de autenticación son compatibles con la filosofía REST y por qué?
Respuestas:
Un servicio ReSTful ideal permite a los clientes (que pueden no estar en el navegador) realizar cualquier tarea necesaria en una solicitud ; porque el estado completo necesario para hacerlo lo tiene el cliente, no el servidor. Dado que el cliente tiene el control total del estado, puede crear el estado por sí mismo (si eso es legítimo), y solo hablar con la API para "hacerlo".
Requerir cookies puede dificultarlo. Para los clientes además de los navegadores, administrar cookies es un inconveniente bastante grande en comparación con los parámetros de consulta, los encabezados de solicitud simples o el cuerpo de la solicitud. Por otro lado, en el navegador, el uso de cookies puede hacer muchas cosas mucho más simples.
Así que una API podría mirar primero en la Authorization
cabecera de los datos de autenticación que necesita, ya que eso es probablemente el lugar donde los clientes distintas de los navegadores preferirán lo puso, pero para simplificar y agilizar los clientes basados en navegador, puede también comprobar si hay una cookie de sesión para el inicio de sesión del lado del servidor, pero solo si Authorization
falta el encabezado normal .
Otro ejemplo podría ser una solicitud compleja que normalmente requiere una gran cantidad de parámetros establecidos. Un cliente no interactivo no tendría problemas para agrupar todos esos datos en una sola solicitud, pero una interfaz basada en formularios HTML podría preferir dividir la solicitud en varias páginas (algo así como un conjunto de páginas de 'asistente') para que los usuarios no se presenten con opciones que no son aplicables según las selecciones anteriores. Todas las páginas intermedias podrían almacenar los valores en cookies del lado del cliente, de modo que solo la última página, donde el usuario realmente envía la solicitud, tenga algún efecto secundario en el servidor. La API podría buscar los atributos necesarios en el cuerpo de la solicitud y volver a mirar las cookies si los parámetros necesarios no estuvieran allí.
Editar: en RE al comentario de @ Konrad a continuación:
Los tokens en comparación son más difíciles de implementar, especialmente porque no puede invalidar fácilmente el token sin almacenarlos en algún lugar.
er ... estás validando las cookies en el lado del servidor, ¿verdad? El hecho de que le haya dicho al navegador que descarte una cookie después de 24 horas no significa que lo hará. Esa cookie podría ser guardada por un usuario altamente técnico y reutilizada mucho después de que haya "caducado".
Si no desea almacenar los datos de la sesión en el lado del servidor, debe almacenarlos en el token (cookie u otro). Un token de autenticación autónomo a veces se llama macarrón. La forma en que esto se pasa entre el cliente y el servidor (ya sea por cookie, como encabezados adicionales o en la entidad de solicitud) es totalmente independiente del mecanismo de autenticación.
HttpClient
.NET puede usar cookies sin ningún problema y realmente no necesita pensar en ello. Los tokens en comparación son más difíciles de implementar, especialmente porque no puede invalidar fácilmente el token sin almacenarlos en algún lugar.
curl
o wget
, administrar cookies es bastante inconveniente y realmente tienes que pensar mucho en ellas. Respondí a tu otro punto editando mi respuesta.
Sí y no: depende de cómo lo use.
Las cookies si se usan para mantener el estado del cliente en el cliente, para el cliente, del cliente y por el cliente, entonces son relajantes.
Si está almacenando el estado del servidor en la cookie, básicamente está transfiriendo la carga al cliente, lo que no es tranquilo.
Entonces, ¿cuáles son algunos ejemplos?
Sosegado:
No es tranquilo
La tranquilidad proviene de la apatridia del servidor. Los clientes pueden mantener el estado de la aplicación y enviarla al servidor para decir dónde están para que el servidor pueda decidir a dónde ir desde allí. Básicamente, las sesiones / estados necesitan datos históricos y dependen de solicitudes pasadas, por así decirlo, las aplicaciones relajantes idealmente no lo son (no es viable tener una aplicación 100% pura si va a tener una pantalla de inicio de sesión :)
Uno puede usar cookies. REST les permite.
REST requiere que cualquier información de sesión se almacene en el lado del cliente, pero cuando se trata de autenticación, parte de la información debe permanecer en el lado del servidor por razones de seguridad.
De una de mis publicaciones de blog , hay un acuerdo general de que los datos de autenticación se consideran fuera del alcance con respecto a REST. Por lo tanto, está bien que los servidores mantengan parte de los datos de esta sesión.