web applications - seguridad - Autenticación REST para aplicaciones web

construyendo una web api rest segura con json web token en.net parte ii

Question

Hola, ya escribí esta observación y pregunta sobre esta 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 una aplicación basada en navegador (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 se puede agregar la recuperación de contraseñas, 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 ventana
• los tiempos de espera son difíciles

Un artículo muy perspicaz que aborda estos puntos por punto está here , pero esto resulta en una gran cantidad de hackers javascript específicos del navegador, soluciones alternativas a las soluciones provisionales, etc. 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 insignia 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 el contenido de esta parte del estado del lado del cliente puede ser determinado por el servidor como parte de su respuesta.

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

• Una sesión asigna una clave a un ID de usuario (y posiblemente una última marca de tiempo de acción para los tiempos de espera)
• Si existe una sesión , entonces eso significa que la clave es válida.
• Iniciar sesión significa POSTing to / session, una nueva clave se configura como una cookie
• Cerrar sesión significa BORRAR / 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 puede usarse para acceder a los recursos de traducción, etc. Siento que es lo mismo, pero tal vez otros no? ¿Qué piensan chicos?

Answer 1

Sé que esta es una pregunta un poco antigua, pero creo que muchas de las preguntas aquí se han abordado en diferentes áreas. En particular, creo que el Protocolo OAuth 2.0 ha estado considerando muchas de estas preguntas; No me siento lo suficientemente autoritario para proporcionar un resumen de sus respuestas aquí, pero el sitio vinculado tiene muchos casos de uso diferentes explicados explícitamente, lo que parece muy útil para esta pregunta, incluso si el OAuth 2.0 completo no es realmente necesario aquí.

Answer 2

Una pregunta interesante. Estoy terminando una implementación de la API REST ahora mismo, habiendo usado mod_rewrite y PHP. Utiliza autenticación básica HTTP a través de HTTPS. Hasta ahora estamos trabajando en un cliente de Palm Pre. El chico que desarrollaba ese cliente estaba un poco desilusionado por tener que mantener un registro de las credenciales de usuario para enviarlas con cada solicitud.

La idea de exponer SESSION como un recurso es interesante. Incluirlo aún violaría los estrictos principios de REST. Incluso si expone SESSION como un recurso, seguirá usando el servidor para realizar un seguimiento del estado del cliente. La adhesión estricta a REST probablemente requiera el uso de cookies, ya que esa es la memoria persistente del lado del cliente disponible desde el navegador. El problema es que te deja crear un cliente de JavaScript (o FLash?) Para administrar las solicitudes HTTP del lado del cliente si no quieres que los usuarios interactúen con la recopilación de credenciales HTTP implementada por el navegador.

Una herramienta que me ha resultado útil es la herramienta REST Client para Firefox ... pero aún así, introduzco mis credenciales en la ventana emergente del navegador estándar, incluso cuando la estoy usando.

Debo admitir que he incluido algunos hacks en mi implementación. Si todo lo que está haciendo es usar sesiones para permitir la prueba / navegación de la API por parte de desarrolladores potenciales o algo así, no creo que el uso de la autenticación basada en sesiones sea tan importante. Los puristas no estarían de acuerdo, estoy seguro. Realmente eso es lo que se reduce a ... esto es esencialmente un argumento académico. En situaciones de la vida real tienes que hacer lo que funciona.

... añadiendo a esto el 23/10/2012 ...

La insistencia de la metodología REST en hacer que el cliente realice un seguimiento de su propio estado no es solo académica. Tiene implicaciones importantes para la escalabilidad y la direccionabilidad de los recursos expuestos. Cuando digo esto, asumo que por estado del cliente estamos hablando de atributos específicos para un usuario solicitante que afectan las respuestas emitidas por la (s) interfaz (s) de REST. Una de las fortalezas de REST es su direccionabilidad. Cuando realiza sus respuestas de alguna manera en función de la información que no se pasa en la solicitud, comienza a hacer eso. Solo una ocurrencia tardía ... 3 años después, jajaja.