Hola ya escribí esta observación y pregunta enesta pregunta anteriormente, pero solo más tarde noté que era una pregunta antigua y "muerta". Como realmente me gustaría conocer algunos puntos de vista de otros, lo estoy replanteando como una nueva pregunta.

A la pregunta de cómo realizar la autenticación RESTAMENTE, las personas generalmente gritan con entusiasmo "Autenticación HTTP". Sin embargo, tengo dudas de si esas personas alguna vez intentaron hacer un navegador basado ensolicitud (en lugar de un servicio web de máquina a máquina) con REST. (sin intención de ofender, simplemente creo que nunca se enfrentaron a las complicaciones)

Los problemas que encontré al usar la autenticación HTTP en los servicios REST que producen páginas HTML para ver en un navegador son:

el usuario normalmente recibe un cuadro de inicio de sesión feo hecho por el navegador, que es muy hostil para el usuario. no puede agregar recuperación de contraseña, cajas de ayuda, etcétera.cerrar sesión o iniciar sesión con un nombre diferente es un problema: los navegadores seguirán enviando información de autenticación al sitio hasta que cierre la ventanalos tiempos de espera son difíciles

Un artículo muy perspicaz que aborda estos puntos por punto esaquí, pero esto resulta a unamucho de hackers javascript específicos del navegador, soluciones a las soluciones alternativas, etcétera. Como tal, tampoco es compatible con versiones posteriores, por lo que requerirá un mantenimiento constante a medida que se lancen nuevos navegadores. No considero que el diseño sea limpio y claro, además creo que es mucho trabajo extra y dolor de cabeza solo para poder mostrar con entusiasmo mi distintivo REST a mis amigos.

Creo que las cookies son la solución. Pero espera, las galletas son malas, ¿no? No, no lo son, la forma en que se usan las cookies a menudo es malvada. Una cookie en sí misma es solo una parte de la información del lado del cliente, al igual que la información de autenticación HTTP que el navegador mantendría al tanto mientras navegas. Y esta información del lado del cliente se envía al servidor en cada solicitud, de nuevo, al igual que la información de autenticación HTTP. Conceptualmente, la única diferencia es que lacontenido de este pedazo de estado del lado del cliente puede ser determinado por elservidor Como parte de su respuesta.

Al hacer de las sesiones un recurso RESTful con solo las siguientes reglas:

A sesión asigna una clave a un ID de usuario (y posiblemente una marca de tiempo de última acción para los tiempos de espera)Si unsesión existe, entonces eso significa que la clave es válida.Iniciar sesión significa POSTing to / session, una nueva clave se configura como una cookieEl cierre de sesión significa ELIMINACIÓN / sesiones / {clave} (con POST sobrecargado, recuerde, somos un navegador y HTML 5 es un largo camino por recorrer)La autenticación se realiza enviando la clave como una cookie en cada solicitud y comprobando si la sesión existe y si es válida.

La única diferencia con la autenticación HTTP, ahora, es que la clave de autenticación es generada por el servidor y enviada al cliente que continúa enviándola, en lugar de que el cliente la calcule a partir de las credenciales ingresadas.

Creo que esta es una solución suficiente que funciona bien, pero debo admitir que no soy lo suficientemente experto en seguridad para identificar posibles agujeros en este esquema; todo lo que sé es que cientos de aplicaciones web que no son RESTful usan esencialmente la misma protocolo de inicio de sesión ($ _SESSION inphp, HttpSession en j2ee, etc.). El contenido del encabezado de la cookie se usa simplemente para abordar un recurso del lado del servidor, al igual que un lenguaje de aceptación se puede usar para acceder a los recursos de traducción, etc. Siento que es lo mismo, pero tal vez otros no? ¿Qué piensan chicos?