Autenticación JWT vs OAuth
Tengo un nuevo SPA con un modelo de autenticación sin estado usando JWT. A menudo me piden que refiera a OAuth para los flujos de autenticación, como pedirme que envíe 'tokens al portador' para cada solicitud en lugar de un simple encabezado 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 TOKEN XSRF para evitar el XSRF, pero se me pide que lo mantenga ¿separados? Debo mantenerlos separados? Cualquier ayuda aquí será apreciada y podría conducir a un conjunto de directrices para la comunidad.
7 answers
TL; DR Si tiene escenarios muy simples, como una sola aplicación cliente, una sola API, entonces puede que no valga la pena ir a OAuth 2.0, por otro lado, muchos clientes diferentes (basados en navegador, móviles nativos, del lado del servidor, etc.) y luego adherirse a las reglas de OAuth 2.0 podría hacerlo más manejable que intentar rodar su propio sistema.
Como se indica en otra respuesta, JWT (Learn JSON Web Tokens) es solo un formato de token, define un formato compacto y autónomo mecanismo para la transmisión de datos entre las partes de una manera que pueda 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 autónomo (el token real contiene información sobre un tema dado) también son una buena opción para implementar mecanismos de autenticación sin estado (también conocido como Mira mum, no sessions!). Al ir por esta ruta y lo único que una fiesta debe presentarse para que se le conceda acceso a un recurso protegido es el token en sí, el token en cuestión puede llamarse un token portador.
En la práctica, lo que estás haciendo ya se puede clasificar como basado en tokens al portador. Sin embargo, considere que no está utilizando tokens de portador como se especifica en las especificaciones relacionadas con OAuth 2.0 (consulte RFC 6750). Eso implicaría, confiar en el encabezado HTTP Authorization y usar el esquema de autenticación Bearer.
Con respecto al uso del JWT para prevenir CSRF sin conocer los detalles exactos es difícil determinar la validez de esa práctica, pero para ser honesto no parece correcto y/o que vale la pena. El siguiente artículo ( Cookies vs Tokens: The Definitive Guide ) puede ser una lectura útil sobre este tema, en particular la sección XSS y XSRF Protection.
Un último consejo, incluso si no necesita completar OAuth 2.0, yo recomendaría encarecidamente pasar su token de acceso dentro del Authorization encabezado en lugar de ir con encabezados personalizados . Si realmente son tokens al portador, siga las reglas del RFC 6750, si no, siempre puede crear un esquema de autenticación personalizado y seguir utilizando ese encabezado.
Los encabezados de autorización son reconocidos y tratados especialmente por servidores y proxies HTTP. Por lo tanto, el uso de dichos encabezados para enviar tokens de acceso a los servidores de recursos reduce la probabilidad de fugas o almacenamiento involuntario de solicitudes autenticadas en general, y especialmente los encabezados de autorización.
(fuente: RFC 6819, sección 5.4.1)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-08-21 15:50:55
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 "autenticación JWT" tienen una apariencia similar cuando se trata de la (2da) etapa donde el Cliente presenta el token al Servidor de recursos: el token se pasa en un encabezado.
Pero "autenticación JWT" no es un estándar y no especifica cómo el Cliente obtiene el token en primer lugar (la 1a etapa). Ahí es donde la complejidad percibida of OAuth viene de: también define varias formas en las que el Cliente puede obtener un token de acceso desde algo que se llama un Servidor de Autorización.
Así que la diferencia real es que JWT es solo un formato de token, OAuth 2.0 es un protocolo (que puede usar un JWT como formato de token).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-10-07 07:12:05
En primer lugar, tenemos que diferenciar JWT y OAuth. Básicamente, JWT es un formato de token. OAuth es un marco de autenticación que puede usar JWT como token. OAuth utiliza almacenamiento del lado del servidor y del lado del cliente. Si quieres hacer logout real debes ir con OAuth2. La autenticación con token JWT no puede cerrar sesión en realidad. Porque no tiene un servidor de autenticación que realice un seguimiento de los tokens. Si desea proporcionar una API a clientes de terceros, también debe usar OAuth2. OAuth2 es muy flexible. JWT la implementación es muy fácil y no toma mucho tiempo implementarla. Si su aplicación necesita este tipo de flexibilidad, debe elegir OAuth2. Pero si no necesita este escenario de caso de uso, implementar OAuth2 es una pérdida de tiempo.
El token XSRF siempre se envía al cliente en cada encabezado de respuesta. No importa si un token CSRF se envía en un token JWT o no, porque el token CSRF está protegido consigo mismo. Por lo tanto, enviar token CSRF en JWT es innecesario.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-12-07 02:29:32
Parece que todos los que respondieron aquí perdieron el punto discutible de OAUTH
De Wikipedia
OAuth es un estándar abierto para la delegación de acceso, comúnmente utilizado como una forma para que los usuarios de Internet otorguen acceso a sitios web o aplicaciones a su información en otros sitios web, pero sin darles las contraseñas.[1] Este mecanismo es utilizado por empresas como Google, Facebook, Microsoft y Twitter para permitir a los usuarios compartir información sobre sus cuentas con aplicaciones o sitios web de terceros.
El punto clave aquí es access delegation. ¿Por qué alguien crearía OAUTH cuando hay una autenticación basada en id / pwd, respaldada por autenticación multifactorizada como OTPs y, además, puede ser protegida por JWT que se utilizan para asegurar el acceso a las rutas (como los ámbitos en OAUTH) y establecer la caducidad del acceso
No tiene sentido usar OAUTH si los consumidores acceden a sus recursos(sus puntos finales) solo a través de sus sitios web de confianza (o aplicaciones) que son sus de nuevo alojado en sus puntos finales
Solo puede usar la autenticación OAUTH si es un OAUTH provider en los casos en que los propietarios de recursos (usuarios) desean acceder a sus recursos(puntos finales) a través de un cliente de terceros (aplicación externa). Y está creado exactamente para el mismo propósito, aunque puede abusar de él en general
Otra nota importante:
Está usando libremente la palabra authentication para JWT y OAUTH, pero ninguno proporciona el mecanismo de autenticación. Sí uno es un el mecanismo de token y el otro es el protocolo, pero una vez autenticados solo se utilizan para la autorización (administración de acceso). Debe respaldar OAUTH con autenticación de tipo OPENID o con sus propias credenciales de cliente
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-07-16 16:19:19
JWT (JSON Web Tokens)- Es solo un formato de token. Los tokens JWT son estructuras de datos codificadas JSON que contienen información sobre el emisor, el sujeto (reclamaciones), el tiempo de caducidad, etc. Está firmado para prueba de manipulación y autenticidad y se puede cifrar para proteger la información del token utilizando un enfoque simétrico o asimétrico. JWT es más simple que SAML 1.1/2.0 y es compatible con todos los dispositivos y es más potente que SWT(Simple Web Token).
OAuth2 - OAuth2 resolver un problema ese usuario desea acceder a los datos utilizando software cliente como aplicaciones web basadas en navegación, aplicaciones móviles nativas o aplicaciones de escritorio. OAuth2 es solo para la autorización, el software del cliente puede ser autorizado para acceder a los recursos en nombre del usuario final utilizando el token de acceso.
OpenID Connect - OpenID Connect se construye sobre OAuth2 y agrega autenticación. OpenID Connect agregue alguna restricción a OAuth2 como userInfo Endpoint, ID Token, discovery y registro dinámico de proveedores de OpenID Connect y gestión de sesiones. JWT es el formato obligatorio para el token.
Protección CSRF - No necesita implementar la protección CSRF si no almacena token en la cookie del navegador.
Puedes leer más detalles aquí http://proficientblog.com/microservices-security /
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-01-16 13:34:16
JWT es un protocolo de autenticación en el que permitimos que las notificaciones codificadas (token) se transfieran entre dos partes (cliente y servidor) y el token se emite tras la identificación del cliente. con cada solicitud posterior enviamos el token
Considerando que Oauth2 es un framework de autenticación, donde tiene procedimientos generales y configuraciones definidas por framework. JWT puede utilizarse como mecanismo dentro de Oauth2
Puedes leer más sobre esto aquí
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-02-21 03:13:47
Jwt es un estricto conjunto de instrucciones para la emisión y validación de tokens de acceso firmados. Los tokens contienen notificaciones que son utilizadas por una aplicación para limitar el acceso a un usuario
OAuth2 por otro lado no es un protocolo, es un marco de autorización delegada. piense en una guía muy detallada, para permitir que los usuarios y las aplicaciones autoricen permisos específicos para otras aplicaciones en configuraciones privadas y públicas. OpenID Connect que se encuentra en la parte superior de OAUTH2 le da autenticación y Authorization.it detalles de cómo múltiples roles diferentes, usuarios en su sistema, aplicaciones del lado del servidor como una API y clientes como sitios web o aplicaciones móviles nativas, pueden autenticarse entre sí
Nota oauth2 puede trabajar con jwt, implementación flexible, extensible a diferentes aplicaciones
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-02-04 17:31:19