restful - rest basic authentication

Autenticación REST (14)

Aquí hay una verdadera y completa solución de autenticación RESTful:

Cree un par de claves públicas / privadas en el servidor de autenticación.
Distribuir la clave pública a todos los servidores.
Cuando un cliente se autentica:
3.1. emitir un token que contenga lo siguiente:
- Tiempo de expiración
- nombre de usuario (opcional)
- IP de los usuarios (opcional)
- hash de una contraseña (opcional)
3.2. Cifra el token con la clave privada.
3.3. Enviar el token cifrado de nuevo al usuario.
Cuando el usuario accede a cualquier API, también debe pasar su token de autenticación.
Los servidores pueden verificar que el token es válido descifrando mediante la clave pública del servidor de autenticación.

Esto es autenticación sin estado / RESTful.

Tenga en cuenta que si se incluyera un hash de contraseña, el usuario también enviaría la contraseña sin cifrar junto con el token de autenticación. El servidor pudo verificar que la contraseña coincidía con la contraseña que se utilizó para crear el token de autenticación comparando los hashes. Una conexión segura utilizando algo como HTTPS sería necesaria. Javascript en el lado del cliente podría manejar la obtención de la contraseña del usuario y su almacenamiento, ya sea en la memoria o en una cookie, posiblemente encriptada con la clave pública del servidor.

¿Qué significa la autenticación RESTful y cómo funciona? No puedo encontrar una buena visión general en Google. Mi único entendimiento es que usted pasa la clave de sesión (remeberal) en la URL, pero esto podría estar terriblemente mal.

Cómo manejar la autenticación en una arquitectura RESTful Cliente-Servidor es una cuestión de debate.

Comúnmente, se puede lograr, en el mundo SOA sobre HTTP a través de:

Autenticación básica HTTP a través de HTTPS;
Cookies y gestión de sesiones;
Token en encabezados HTTP (por ejemplo, OAuth 2.0 + JWT);
Autenticación de consulta con parámetros de firma adicionales.

Tendrá que adaptar, o incluso mezclar mejor esas técnicas, para que coincida con su arquitectura de software en el mejor de los casos.

Cada esquema de autenticación tiene sus propios PRO y CON, según el propósito de su política de seguridad y arquitectura de software.

Autenticación básica HTTP a través de HTTPS

Esta primera solución, basada en el protocolo HTTPS estándar, es utilizada por la mayoría de los servicios web.

GET /spec.html HTTP/1.1 Host: www.example.org Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Es fácil de implementar, está disponible de forma predeterminada en todos los navegadores, pero tiene algunos inconvenientes conocidos, como la ventana de autenticación horrible que se muestra en el navegador, que persistirá (no hay una característica similar a LogOut aquí), algún consumo de CPU adicional del lado del servidor, y el hecho de que el nombre de usuario y la contraseña se transmiten (a través de HTTPS) al Servidor (debería ser más seguro permitir que la contraseña permanezca solo en el lado del cliente, durante la entrada del teclado, y se almacene como hash seguro en el Servidor) .

Podemos usar Autenticación Digest , pero también requiere HTTPS, ya que es vulnerable a los MiM de MiM o Replay , y es específico de HTTP.

Sesión a través de Cookies

Para ser honesto, una sesión administrada en el servidor no es realmente sin estado.

Una posibilidad podría ser mantener todos los datos dentro del contenido de la cookie. Y, por diseño, la cookie se maneja en el lado del servidor (el cliente, de hecho, ni siquiera intenta interpretar esta información de la cookie: solo la devuelve al servidor en cada solicitud sucesiva). Pero estos datos de cookies son datos de estado de la aplicación, por lo que el cliente debe administrarlos, no el servidor, en un mundo sin estado.

GET /spec.html HTTP/1.1 Host: www.example.org Cookie: theme=light; sessionToken=abc123

La técnica de las cookies en sí misma está vinculada a HTTP, por lo que no es realmente RESTful, que debería ser independiente del protocolo, IMHO. Es vulnerable a los ataques MiM o Replay .

Concedido a través de Token (OAuth2)

Una alternativa es colocar un token dentro de los encabezados HTTP para que la solicitud sea autenticada. Esto es lo que hace OAuth 2.0, por ejemplo. Ver el RFC 6749 :

GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer mF_9.B5f-4.1JqM

En resumen, esto es muy similar a una cookie y tiene los mismos problemas: no sin estado, se basa en los detalles de la transmisión HTTP y está sujeto a muchas debilidades de seguridad , incluidos MiM y Replay, por lo que solo se debe usar a través de HTTPS. Normalmente, un JWT se utiliza como un token.

Autenticación de consulta

La autenticación de consulta consiste en firmar cada solicitud RESTful a través de algunos parámetros adicionales en el URI. Vea este artículo de referencia .

Fue definido como tal en este artículo:

Todas las consultas REST deben autenticarse firmando los parámetros de consulta ordenados en minúsculas, en orden alfabético, utilizando la credencial privada como el token de firma. La firma debe ocurrir antes de que la URL codifique la cadena de consulta.

Esta técnica es quizás la más compatible con una arquitectura sin estado, y también puede implementarse con una administración de sesión ligera (usando sesiones en memoria en lugar de persistencia de base de datos).

Por ejemplo, aquí hay un ejemplo de URI genérico del enlace anterior:

GET /object?apiKey=Qwerty2010

debe transmitirse como tal:

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

La cadena que se firma es /object?apikey=Qwerty2010&timestamp=1261496500 y la firma es el hash SHA256 de esa cadena usando el componente privado de la clave API.

El almacenamiento en caché de datos del lado del servidor puede estar siempre disponible. Por ejemplo, en nuestro marco, almacenamos en caché las respuestas en el nivel de SQL, no en el nivel de URI. Así que agregar este parámetro extra no rompe el mecanismo de caché.

Consulte este artículo para obtener algunos detalles sobre la autenticación RESTful en nuestro marco ORM / SOA / MVC cliente-servidor, basado en JSON y REST. Como permitimos la comunicación no solo a través de HTTP / 1.1, sino también de canalizaciones con nombre o mensajes GDI (localmente), intentamos implementar un patrón de autenticación verdaderamente REST, y no confiar en la especificidad de HTTP (como el encabezado o las cookies).

Nota posterior : agregar una firma en el URI puede verse como una mala práctica (ya que, por ejemplo, aparecerá en los registros del servidor http), por lo que debe mitigarse, por ejemplo, mediante un TTL adecuado para evitar repeticiones. Pero si sus registros http están comprometidos, seguramente tendrá problemas de seguridad más grandes.

En la práctica, la próxima autenticación de token MAC para OAuth 2.0 puede ser una gran mejora con respecto al esquema actual "Concedido por token". Pero esto sigue siendo un trabajo en progreso y está vinculado a la transmisión HTTP.

Conclusión

Vale la pena concluir que REST no solo está basado en HTTP, incluso si, en la práctica, también se implementa principalmente sobre HTTP. REST puede usar otras capas de comunicación. Por lo tanto, una autenticación REST no es solo un sinónimo de autenticación HTTP, sea cual sea la respuesta de Google. Incluso no debería utilizar el mecanismo HTTP, sino que debe abstraerse de la capa de comunicación. Y si utiliza la comunicación HTTP, gracias a la iniciativa Let''s Encrypt, no hay razón para no usar el HTTPS adecuado, que se requiere además de cualquier esquema de autenticación.

Ciertamente no se trata de "claves de sesión", ya que generalmente se usa para referirse a la autenticación sin sesión que se realiza dentro de todas las restricciones de REST. Cada solicitud se describe a sí misma y contiene suficiente información para autorizar la solicitud por sí misma sin ningún estado de aplicación del lado del servidor.

La forma más fácil de abordar esto es comenzar con los mecanismos de autenticación integrados de HTTP en RFC 2617 .

Dudo si las personas que gritaban con entusiasmo "Autenticación HTTP" 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 ofensa, simplemente creo que nunca enfrentaron 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 obtiene 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 provisionales para soluciones alternativas, 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 es el mal. 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
El cierre de sesión significa ELIMINACIÓN / sesiones / {clave} (con el POST sobrecargado, recuerde, somos un navegador, y HTML 5 está aún 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.

converter42 agrega que al usar https (que deberíamos), es importante que la cookie tenga su marca de seguridad establecida para que la información de autenticación nunca se envíe a través de una conexión no segura. Gran punto, no lo había visto yo mismo.

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 en PHP, HttpSession en Java EE, 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?

El artículo "muy perspicaz" mencionado por @skrebel ( here ) trata sobre un método de autenticación complicado pero realmente roto.

Puede intentar visitar la página (que se supone que solo se puede ver para usuarios autenticados) http://www.berenddeboer.net/rest/site/authenticated.html sin credenciales de inicio de sesión.

(Lo siento, no puedo comentar sobre la respuesta).

Yo diría que el REST y la autenticación simplemente no se mezclan. REST significa apátrida pero ''autenticado'' es un estado. No puedes tenerlos a ambos en la misma capa. Si usted es un defensor RESTful y no está de acuerdo con los estados, entonces tiene que usar HTTPS (es decir, dejar el problema de seguridad en otra capa).

En primer lugar, un servicio web RESTful es STATELESS (o, en otras palabras, SESSIONLESS ). Por lo tanto, un servicio RESTful no tiene ni debe tener un concepto de sesión o cookies involucradas. La forma de realizar la autenticación o la autorización en el servicio RESTful es mediante el uso del encabezado de autorización HTTP, tal como se define en las especificaciones de RFC 2616 HTTP. Cada solicitud individual debe contener el encabezado de Autorización HTTP, y la solicitud debe enviarse a través de una conexión HTTP (SSL). Esta es la forma correcta de realizar la autenticación y verificar la autorización de las solicitudes en los servicios web HTTP RESTful. He implementado un servicio web RESTful para la aplicación Cisco PRIME Performance Manager en Cisco Systems. Y como parte de ese servicio web, también he implementado la autenticación / autorización.

Rubens Gomes.

Para ser honesto contigo, he visto grandes respuestas aquí, pero algo que me molesta un poco es cuando alguien llevará todo el concepto de Stateless a un extremo en el que se convierta en dogmático. Me recuerda a esos viejos fanáticos de Smalltalk que solo querían abrazar OO puro y si algo no es un objeto, entonces lo estás haciendo mal. Dáme un respiro.

Se supone que el enfoque RESTful hace que su vida sea más fácil y reduzca los gastos generales y el costo de las sesiones, intente seguirlo como es sabio, pero en el momento en que sigue una disciplina (cualquier disciplina / directriz) hasta el extremo donde está Ya no proporciona el beneficio para el que estaba destinado, entonces lo está haciendo mal. Algunos de los mejores lenguajes de hoy tienen programación funcional y orientación a objetos.

Si la forma más fácil de resolver su problema es almacenar la clave de autenticación en una cookie y enviarla en el encabezado HTTP, entonces hágalo, pero no lo abuse. Recuerde que las sesiones son malas cuando se vuelven pesadas y grandes, si toda su sesión consiste en una cadena corta que contiene una clave, ¿cuál es el problema?

Estoy abierto a aceptar correcciones en los comentarios, pero simplemente no veo el punto (hasta ahora) de hacer que nuestras vidas sean miserables para simplemente evitar tener un gran diccionario de hashes en nuestro servidor.

Suficiente ya se ha dicho sobre este tema por gente buena aquí. Pero aquí están mis 2 centavos.

Hay 2 modos de interacción:

humano a máquina (HTM)
máquina a máquina (MTM)

La máquina es el denominador común, expresado como las API REST, y los actores / clientes son los humanos o las máquinas.

Ahora, en una arquitectura verdaderamente REST, el concepto de apatridia implica que todos los estados de aplicación relevantes (es decir, los estados del lado del cliente) deben proporcionarse con cada solicitud. Por relevante, se entiende que todo lo que requiera la API REST para procesar la solicitud y proporcionar una respuesta adecuada.

Cuando consideramos esto en el contexto de las aplicaciones de persona a máquina, "basado en navegador" como señala Skrebbel anteriormente, esto significa que la aplicación (web) que se ejecuta en el navegador deberá enviar su estado e información relevante con cada solicitud. hace a las API de REST back-end.

Considere esto: Usted tiene un activo expuesto de la plataforma de datos / información de las API REST. Quizás tenga una plataforma de BI de autoservicio que maneje todos los cubos de datos. Pero desea que sus clientes (humanos) accedan a esta a través de (1) aplicación web, (2) aplicación móvil y (3) alguna aplicación de terceros. Al final, incluso la cadena de MTM lleva a HTM, a la derecha. Así que los usuarios humanos permanecen en la cúspide de la cadena de información.

En los primeros 2 casos, tiene un caso para la interacción persona a máquina, ya que la información la consume realmente un usuario humano. En el último caso, tiene un programa de máquina que consume las API REST.

El concepto de autenticación se aplica en todos los ámbitos. ¿Cómo diseñará esto para que se pueda acceder a sus API REST de manera uniforme y segura? La forma en que veo esto, hay 2 maneras:

Way-1:

No hay login, para empezar. Cada solicitud realiza el inicio de sesión.
El cliente envía sus parámetros de identificación + los parámetros específicos de solicitud con cada solicitud
La API REST los toma, da la vuelta, hace ping al almacén de usuarios (sea lo que sea) y confirma la autenticación
Si la autenticación está establecida, se atiende la solicitud; De lo contrario, niega con el código de estado HTTP apropiado.
Repita lo anterior para cada solicitud en todas las API REST de su catálogo

Way-2:

El cliente comienza con una solicitud de autenticación.
Una API REST de inicio de sesión manejará todas estas solicitudes
Toma los parámetros de autenticación (clave de API, uid / pwd o lo que elija) y verifica la autenticación en el almacén de usuarios (LDAP, AD o MySQL DB, etc.)
Si se verifica, crea un token de autenticación y se lo entrega al cliente / llamante
La persona que llama luego envía esta solicitud de token de autenticación + parámetros específicos con cada solicitud subsiguiente a otras API de REST empresariales, hasta que se desconecte o hasta que expire el contrato de arrendamiento

Claramente, en Way-2, las API REST necesitarán una forma de reconocer y confiar en el token como válido. La API de inicio de sesión realizó la verificación de autenticación y, por lo tanto, otras API REST de su catálogo deben confiar en la "clave de valet".

Esto, por supuesto, significa que la clave / token de autenticación deberá almacenarse y compartirse entre las API de REST. Este repositorio de token de confianza compartido puede ser local / federado, permitiendo que las API REST de otras organizaciones confíen entre sí.

Pero yo divago.

El punto es que un "estado" (sobre el estado autenticado del cliente) debe mantenerse y compartirse para que todas las API REST puedan crear un círculo de confianza. Si no hacemos esto, que es el Way-1, debemos aceptar que se debe realizar un acto de autenticación para cualquier / todas las solicitudes que lleguen.

Realizar la autenticación es un proceso que consume muchos recursos. Imagine la ejecución de consultas SQL, para cada solicitud entrante, en su almacén de usuarios para verificar la coincidencia de uid / pwd. O, para cifrar y realizar coincidencias de hash (el estilo de AWS). Y arquitectónicamente, cada API REST tendrá que realizar esto, sospecho, usando un servicio de inicio de sesión de back-end común. Porque, si no lo haces, entonces ensucias el código de autenticación en todas partes. Un gran desastre.

Así que más las capas, más la latencia.

Ahora, tome Way-1 y aplique a HTM. ¿A tu usuario (humano) realmente le importa si tienes que enviar uid / pwd / hash o lo que sea con cada solicitud? No, siempre y cuando no la molestes lanzando la página de autenticación / inicio de sesión cada segundo. Buena suerte tener clientes si lo haces. Entonces, lo que hará es almacenar la información de inicio de sesión en algún lugar del lado del cliente, en el navegador, desde el principio, y enviarla con cada solicitud realizada. Para el usuario (humano), ella ya ha iniciado sesión y hay una "sesión" disponible. Pero en realidad, ella es autenticada en cada solicitud.

Lo mismo con Way-2. Tu usuario (humano) nunca se dará cuenta. Así que no se hizo daño.

¿Qué pasa si aplicamos Way-1 a MTM? En este caso, ya que es una máquina, podemos aburrir a este tipo pidiéndole que envíe información de autenticación con cada solicitud. ¡A nadie le importa! Realizar Way-2 en MTM no provocará ninguna reacción especial; Es una máquina maldita. ¡Podría importarle menos!

Así que realmente, la pregunta es qué se adapta a su necesidad. La apatridia tiene un precio que pagar. Paga el precio y sigue adelante. Si quieres ser un purista, paga el precio por eso también, y sigue adelante.

Al final, las filosofías no importan. Lo que realmente importa es el descubrimiento de la información, la presentación y la experiencia de consumo. Si la gente ama tus APIs, hiciste tu trabajo.

Consejos válidos para asegurar cualquier aplicación web.

Si desea asegurar su aplicación, entonces debería comenzar por utilizar HTTPS en lugar de HTTP , esto garantiza la creación de un canal seguro entre usted y los usuarios que evitará rastrear los datos enviados a los usuarios y ayudará a mantener los datos. Intercambio confidencial.

Puede usar JWTs (JSON Web Tokens) para asegurar las API RESTful , esto tiene muchos beneficios en comparación con las sesiones del lado del servidor, los beneficios son principalmente:

1- Más escalable, ya que los servidores de su API no tendrán que mantener sesiones para cada usuario (lo que puede ser una gran carga cuando tiene muchas sesiones)

2- Los JWT son autónomos y tienen las reclamaciones que definen el rol del usuario y qué puede acceder y emitir en la fecha y caducidad (después de lo cual JWT no será válido)

3- Más fácil de manejar en los balanceadores de carga y si tiene múltiples servidores API, ya que no tendrá que compartir datos de sesión ni configurar el servidor para enrutar la sesión al mismo servidor, siempre que una solicitud con un JWT llegue a cualquier servidor, se puede autenticar y autorizado

4- Menos presión en su base de datos, ya que no tendrá que almacenar y recuperar constantemente la identificación de sesión y los datos para cada solicitud

5- Los JWT no se pueden manipular si utiliza una clave segura para firmar el JWT, por lo que puede confiar en los reclamos en el JWT que se envía con la solicitud sin tener que verificar la sesión del usuario y si está autorizado o no. , solo puede revisar el JWT y luego está listo para saber quién y qué puede hacer este usuario.

Muchas bibliotecas proporcionan formas fáciles de crear y validar JWT en la mayoría de los lenguajes de programación, por ejemplo: en node.js, uno de los más populares es jsonwebtoken

Dado que las API REST generalmente tienen como objetivo mantener el servidor sin estado, los JWT son más compatibles con ese concepto, ya que cada solicitud se envía con un token de Autorización que es autónomo (JWT) sin que el servidor tenga que realizar un seguimiento de las sesiones de usuario en comparación con las sesiones que Servidor con estado para que recuerde al usuario y su rol, sin embargo, las sesiones también se usan ampliamente y tienen sus ventajas, que puede buscar si lo desea.

Una cosa importante a tener en cuenta es que debe entregar el JWT de forma segura al cliente utilizando HTTPS y guardarlo en un lugar seguro (por ejemplo, en el almacenamiento local).

Puedes aprender más sobre JWTs desde este enlace

Creo que el siguiente enfoque se puede utilizar para la autenticación del servicio REST:

Cree una API RESTful de inicio de sesión para aceptar el nombre de usuario y la contraseña para la autenticación. Utilice el método HTTP POST para evitar el almacenamiento en caché y SSL para la seguridad durante el tránsito En la autenticación exitosa, la API devuelve dos JWT: un token de acceso (validez más corta, por ejemplo, 30 minutos) y un token de actualización (validez más larga, por ejemplo, 24 horas)
El cliente (una interfaz de usuario basada en la web) almacena los JWT en el almacenamiento local y en cada llamada API posterior pasa el token de acceso en el encabezado "Autorización: portador del token de acceso"
La API verifica la validez del token verificando la firma y la fecha de caducidad. Si el token es válido, verifique si el usuario (interpreta el "sub" reclamo en JWT como nombre de usuario) tiene acceso a la API con una búsqueda de caché. Si el usuario está autorizado para acceder a la API, ejecute la lógica de negocios
Si el token ha caducado, la API devuelve el código de respuesta HTTP 400
El cliente, al recibir 400/401, invoca otra API REST con el token de actualización en el encabezado "Autorización: token #refresh" para obtener un nuevo token de acceso.
Al recibir la llamada con el token de actualización, verifique si el token de actualización es válido verificando la firma y la fecha de caducidad. Si el token de actualización es válido, actualice la caché de derechos de acceso del usuario desde la base de datos y devuelva el nuevo token de acceso y el token de actualización. Si el token de actualización no es válido, devuelva el código de respuesta HTTP 400
Si se devuelven un nuevo token de acceso y un token de actualización, vaya al paso 2. Si se devuelve el código de respuesta HTTP 400, el cliente asume que el token de actualización ha caducado y le pide al usuario el nombre de usuario y la contraseña.
Para cerrar sesión, purgar el almacenamiento local

Con este enfoque, estamos realizando la costosa operación de cargar la memoria caché con detalles de derechos de acceso específicos del usuario cada 30 minutos. Por lo tanto, si se revoca un acceso o se otorga un nuevo acceso, demorará 30 minutos en reflejarse o cerrar la sesión y luego iniciar sesión.

El uso de una infraestructura de clave pública en la que el registro de una clave implica una vinculación adecuada garantiza que la clave pública esté vinculada a la persona a la que está asignada de una manera que garantice la no repudio

Ver http://en.wikipedia.org/wiki/Public_key_infrastructure . Si sigue los estándares de PKI adecuados, la persona o el agente que usa la clave robada de manera incorrecta puede ser identificado y bloqueado. Si se requiere que el agente use un certificado, el enlace se vuelve muy ajustado. Un ladrón inteligente y de rápido movimiento puede escapar, pero dejan más migajas.

Para responder a esta pregunta desde mi entendimiento ...

Un sistema de autenticación que utiliza REST para que no tenga que rastrear o administrar realmente a los usuarios en su sistema. Esto se hace usando los métodos HTTP POST, GET, PUT, DELETE. Tomamos estos 4 métodos y pensamos en ellos en términos de interacción de base de datos como CREAR, LEER, ACTUALIZAR, BORRAR (pero en la web usamos POST y GET porque eso es lo que admiten las etiquetas de anclaje actualmente). Entonces, al tratar POST y GET como nuestro CREAR / LEER / ACTUALIZAR / BORRAR (CRUD), podemos diseñar rutas en nuestra aplicación web que podrán deducir qué acción de CRUD estamos logrando.

Por ejemplo, en una aplicación de Ruby on Rails podemos construir nuestra aplicación web de tal manera que si un usuario que ha iniciado sesión visita http://store.com/account/logout , el GET de esa página puede verse como el usuario que intenta cerrar sesión. . En nuestro controlador de rieles, construimos una acción que cierra la sesión del usuario y la envía a la página de inicio.

Un GET en la página de inicio de sesión generaría un formulario. un POST en la página de inicio de sesión se vería como un intento de inicio de sesión, tomará los datos de POST y los utilizará para iniciar sesión.

Para mí, es una práctica de usar métodos HTTP asignados a su base de datos y luego construir un sistema de autenticación teniendo en cuenta que no es necesario pasar por ningún ID de sesión o realizar un seguimiento de las sesiones.

Todavía estoy aprendiendo. Si encuentra que algo que he dicho es incorrecto, corríjame y si aprende más, publíquelo nuevamente aquí. Gracias.

Creo que la autenticación de confianza implica el paso de un token de autenticación como un parámetro en la solicitud. Ejemplos son el uso de apikeys por api''s. No creo que el uso de cookies o autenticación http califique.

Esa es la manera de hacerlo: usar OAuth 2.0 para iniciar sesión .

Puede utilizar otros métodos de autenticación distintos a los de Google, siempre que sea compatible con OAuth.