Cómo manejar la autenticación en una arquitectura RESTful Cliente-Servidor es un tema de debate.
Comúnmente, se puede lograr, en el mundo SOA sobre HTTP a través de:
- Autenticación básica HTTP sobre 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 la arquitectura de su software en el mejor de los casos.
Cada esquema de autenticación tiene sus propios PRO y CON, dependiendo del propósito de su política de seguridad y arquitectura de software.
Autenticación básica HTTP sobre HTTPS
Esta primera solución, basada en el protocolo estándar HTTPS, 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 horrible ventana de autenticación que se muestra en el navegador, que persistirá (no hay una característica similar a LogOut aquí), algo de 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 la autenticación implícita , pero también requiere HTTPS, ya que es vulnerable a ataques 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 las cookies. Y, por diseño, la cookie se maneja en el lado del servidor (el cliente, de hecho, ni siquiera intenta interpretar estos datos 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 puro.
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
La técnica de cookies en sí está vinculada a HTTP, por lo que no es realmente RESTful, que debería ser independiente del protocolo, en mi humilde opinión. Es vulnerable a los ataques MiM o Replay .
Otorgado a través de token (OAuth2)
Una alternativa es colocar un token dentro de los encabezados HTTP para que la solicitud se autentique. Esto es lo que hace OAuth 2.0, por ejemplo. Vea 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 sufre los mismos problemas: no es apátrida, depende de los detalles de transmisión de HTTP y está sujeto a muchas debilidades de seguridad , incluidos MiM y Replay, por lo que debe usarse solo sobre HTTPS. Por lo general, un JWT se usa como 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. Ver este artículo de referencia .
Se definió como tal en este artículo:
Todas las consultas REST deben autenticarse firmando los parámetros de consulta ordenados en orden alfabético en minúsculas utilizando la credencial privada como 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 se puede implementar con una administración de sesión ligera (usando sesiones en memoria en lugar de persistencia DB).
Por ejemplo, aquí hay una muestra genérica de URI del enlace de arriba:
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×tamp=1261496500y 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 a nivel de SQL, no a nivel de URI. Por lo tanto, agregar este parámetro adicional 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. Dado que permitimos la comunicación no solo a través de HTTP / 1.1, sino también canalizaciones con nombre o mensajes GDI (localmente), intentamos implementar un patrón de autenticación verdaderamente RESTful, y no confiar en la especificidad HTTP (como encabezado o 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á mayores problemas de seguridad.
En la práctica, la próxima autenticación de tokens 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 se basa en HTTP, incluso si, en la práctica, también se implementa principalmente a través de HTTP. REST puede usar otras capas de comunicación. Por lo tanto, una autenticación RESTful no es solo un sinónimo de autenticación HTTP, sea lo que sea que Google responda. Incluso no debe usar el mecanismo HTTP en absoluto, sino que debe abstraerse de la capa de comunicación. Y si usa la comunicación HTTP, gracias a la iniciativa Let's Encrypt no hay razón para no usar HTTPS adecuado, que se requiere además de cualquier esquema de autenticación.