Tengo un nuevo SPA con un modelo de autenticación sin estado usando JWT. A menudo me piden que me refiera a OAuth para los flujos de autenticación como pedirme que envíe 'tokens de portador' para cada solicitud en lugar de una simple cabecera de token pero creo que OAuth es mucho más complejo que una simple autenticación basada en JWT. ¿Cuáles son las principales diferencias, debo hacer que la autenticación JWT se comporte como OAuth?
También estoy usando el JWT como mi XSRF-TOKEN para evitar el XSRF pero me piden que los mantenga separados? ¿Debo mantenerlos separados? Cualquier ayuda aquí será apreciada y podría conducir a un conjunto de directrices para la comunidad.
TL;DR Si tienes escenarios muy simples, como una sola aplicación de cliente, una sola API, entonces podría no valer la pena ir a OAuth 2.0, por otro lado, muchos clientes diferentes (basado en el navegador, móvil nativo, del lado del servidor, etc), entonces apegarse a las reglas de OAuth 2.0 podría hacer que sea más manejable que tratar de rodar su propio sistema.
Como se dijo en otra respuesta, JWT (Learn JSON Web Tokens) es sólo un formato de token, define un mecanismo compacto y autocontenido para transmitir datos entre las partes de una manera que puede ser verificada y confiable porque está firmada digitalmente. Además, las reglas de codificación de un JWT también hacen que estos tokens sean muy fáciles de usar dentro del contexto de HTTP.
Al ser autocontenidos (el token real contiene información sobre un sujeto determinado) también son una buena opción para implementar mecanismos de autenticación sin estado (también conocido como ¡Mira mamá, sin sesiones!). Cuando se sigue este camino y lo único que una parte debe presentar para que se le conceda acceso a un recurso protegido es el propio token, el token en cuestión puede llamarse token portador.
En la práctica, lo que está haciendo ya puede clasificarse como basado en tokens de portador. Sin embargo, considere que no está utilizando tokens de portador tal y como se especifica en las especificaciones relacionadas con OAuth 2.0 (véase RFC 6750). Eso implicaría, confiar en la cabecera HTTP Authorization
y utilizar el esquema de autenticación Bearer
.
En cuanto al uso del JWT para prevenir el CSRF sin conocer los detalles exactos es difícil determinar la validez de esa práctica, pero para ser sinceros no parece correcta y/o valiosa. El siguiente artículo (Cookies vs Tokens: The Definitive Guide) puede ser una lectura útil sobre este tema, particularmente la sección Protección contra XSS y XSRF.
Un último consejo, incluso si no necesitas ir al completo con OAuth 2.0, yo recomendaría pasar tu token de acceso dentro de la cabecera Authorization
en lugar de ir con cabeceras personalizadas. Si realmente son tokens de portador sigue las reglas del RFC 6750, si no, siempre puedes crear un esquema de autenticación personalizado y seguir usando esa cabecera.
Las cabeceras de autorización son reconocidas y tratadas especialmente por los proxies y servidores HTTP. Por lo tanto, el uso de dichas cabeceras para el envío de tokens de acceso a los servidores de recursos reduce la probabilidad de filtración o almacenamiento no intencionado de las solicitudes autenticadas en general, y especialmente de las cabeceras de Autorización.
(fuente: RFC 6819, sección 5.4.1)
OAuth 2.0 define un protocolo, es decir, especifica cómo se transfieren los tokens, JWT define un formato de token.
OAuth 2.0 y "La autenticación JWT" tienen un aspecto similar cuando se trata de la (2ª) etapa en la que el Cliente presenta el token al Servidor de Recursos: el token se pasa en una cabecera.
Pero la "autenticación JWT" no es un estándar y no especifica "cómo" el cliente obtiene el token en primer lugar (la primera etapa). De ahí viene la complejidad percibida de OAuth: también define varias formas en las que el Cliente puede obtener un token de acceso de algo que se llama Servidor de Autorización.
Así que la diferencia real es que JWT es sólo un formato de token, OAuth 2.0 es un protocolo (que puede utilizar un JWT como formato de token).
En primer lugar, tenemos que diferenciar JWT y OAuth. Básicamente, JWT es un formato de token. OAuth es un protocolo de autorización que puede utilizar JWT como token. OAuth utiliza el almacenamiento del lado del servidor y del lado del cliente. Si quieres hacer un cierre de sesión real debes ir con OAuth2. La autenticación con el token JWT no puede cerrar la sesión en realidad. Porque no tienes un Servidor de Autenticación que lleve la cuenta de los tokens. Si desea proporcionar una API a los clientes de terceros, debe utilizar OAuth2 también. OAuth2 es muy flexible. La implementación de JWT es muy fácil y no lleva mucho tiempo. Si su aplicación necesita este tipo de flexibilidad, debe ir con OAuth2. Pero si no necesitas este escenario de uso, implementar OAuth2 es una pérdida de tiempo.
El token XSRF siempre se envía al cliente en cada cabecera de respuesta. No importa si se envía un token CSRF en un token JWT o no, porque el token CSRF está asegurado con él mismo. Por lo tanto, enviar el token CSRF en JWT es innecesario.