authentication - tutorial - ¿Cuáles son las principales diferencias entre la autenticación JWT y OAuth?

oauth2 tutorial (8)

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 usar JWT como token. OAuth utiliza almacenamiento del lado del servidor y del lado del cliente. Si desea hacer un cierre de sesión real, debe ir con OAuth2. La autenticación con el token JWT no puede cerrar sesión en realidad. Porque no tiene un servidor de autenticación que realiza un seguimiento de los tokens. Si desea proporcionar una API a clientes de terceros, también debe usar OAuth2. OAuth2 es muy flexible. La implementación de JWT es muy fácil y no lleva mucho tiempo implementarla. Si su aplicación necesita este tipo de flexibilidad, debe optar por 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á asegurado consigo mismo. Por lo tanto, no es necesario enviar el token CSRF en JWT.

Tengo un nuevo SPA con un modelo de autenticación sin estado usando JWT. A menudo se me pide que remita a OAuth para los flujos de autenticación, como pedirme que envíe ''tokens de portador'' para cada solicitud en lugar de un encabezado de token simple, pero creo que OAuth es mucho más complejo que una autenticación basada en JWT simple. ¿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 prevenir el XSRF, pero ¿se me pide que los mantenga separados? ¿Debo mantenerlos separados? Cualquier ayuda aquí será apreciada y podría conducir a un conjunto de pautas para la comunidad.

Encuentra las principales diferencias entre JWT y OAuth

OAuth 2.0 define un protocolo y JWT define un formato de token.
OAuth puede usar JWT como formato de token o token de acceso, que es un token portador.
OpenID connect utiliza principalmente JWT como formato de token.

JWT es un estándar abierto que define una forma compacta y autónoma para transmitir información de forma segura entre las partes. Es un protocolo de autenticación donde permitimos que se transfieran reclamos codificados (tokens) entre dos partes (cliente y servidor) y el token se emite tras la identificación de un cliente. Con cada solicitud posterior enviamos el token.

Mientras que OAuth2 es un marco de autorización, donde tiene procedimientos y configuraciones generales definidos por el marco. JWT se puede usar como mecanismo dentro de OAuth2.

Puedes leer más sobre esto aquí

OAuth o JWT? ¿Cuál usar y por qué?

Jwt es un conjunto estricto de instrucciones para la emisión y validación de tokens de acceso firmados. Los tokens contienen notificaciones que una aplicación utiliza para limitar el acceso a un usuario.

OAuth2 por otro lado no es un protocolo, es un marco de autorización delegado. piense en pautas muy detalladas, para permitir que los usuarios y las aplicaciones autoricen permisos específicos para otras aplicaciones en entornos privados y públicos. OpenID Connect, que se encuentra en la parte superior de OAUTH2, le brinda autenticación y autorización. Detalla 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 con cada otro

Tenga en cuenta que oauth2 puede funcionar con jwt, implementación flexible, ampliable a diferentes aplicaciones

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 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í proviene la complejidad percibida de OAuth: también define varias formas en que el Cliente puede obtener un token de acceso de algo que se llama un Servidor de Autorización.

Entonces, la verdadera diferencia es que JWT es solo un formato de token, OAuth 2.0 es un protocolo (que puede usar un JWT como formato de token).

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 a los sitios web o aplicaciones acceso a su información en otros sitios web pero sin darles las contraseñas. [1] Este mecanismo es utilizado por compañías 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 la access delegation . ¿Por qué alguien crearía OAUTH cuando hay una autenticación basada en id / pwd, respaldada por autenticación multifactorizada como OTP y además puede ser protegida por JWT que se utilizan para asegurar el acceso a las rutas (como ámbitos en OAUTH) y establecer la caducidad de la acceso

No tiene sentido usar OAUTH si los consumidores acceden a sus recursos (sus puntos finales) solo a través de sus sitios web confiables (o aplicaciones) que nuevamente están alojados en sus puntos finales

Puede usar la autenticación OAUTH solo si es un OAUTH provider en los casos en que los propietarios de los recursos (usuarios) desean acceder a sus (sus) recursos (puntos finales) a través de un cliente externo (aplicación externa). Y está creado exactamente para el mismo propósito, aunque puede abusar de él en general

Otra nota importante:
Está utilizando libremente la palabra authentication para JWT y OAUTH pero tampoco proporciona el mecanismo de autenticación. Sí, uno es un mecanismo de token y el otro es un protocolo, pero una vez autenticado, solo se utilizan para la autorización (gestión de acceso). Debe respaldar OAUTH ya sea con autenticación de tipo OPENID o con sus propias credenciales de cliente

JWT (JSON Web Tokens) : es solo un formato de token. Los tokens JWT son estructuras de datos codificadas por JSON que contienen información sobre el emisor, el sujeto (reclamos), el tiempo de vencimiento, 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 resuelve un problema por el cual el usuario desea acceder a los datos utilizando software de cliente como aplicaciones web basadas en navegación, aplicaciones móviles nativas o aplicaciones de escritorio. OAuth2 es solo para 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 basa en OAuth2 y agrega autenticación. OpenID Connect agrega alguna restricción a OAuth2 como UserInfo Endpoint, ID Token, descubrimiento 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 el token en la cookie del navegador.

Puede leer más detalles aquí http://proficientblog.com/microservices-security/

TL; DR Si tiene escenarios muy simples, como una aplicación de un solo cliente, una única 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.), entonces, apegarse a las reglas de OAuth 2.0 podría hacerlo más manejable que tratar de implementar su propio sistema.

Como se indicó en otra respuesta, JWT ( Learn JSON Web Tokens ) es solo un formato de token, define un mecanismo compacto y autónomo para transmitir datos entre las partes de una manera que se puede verificar y confiar porque está firmado digitalmente. Además, las reglas de codificación de un JWT también hacen que estos tokens sean muy fáciles de usar en el contexto de HTTP.

Al ser autónomos (el token real contiene información sobre un tema determinado), también son una buena opción para implementar mecanismos de autenticación sin estado (también conocido como ¡Mira mamá, no hay sesiones! ). Al seguir esta ruta y lo único que una parte debe presentar para que se le otorgue acceso a un recurso protegido es el token en sí, el token en cuestión puede llamarse token de portador.

En la práctica, lo que estás haciendo ya se puede clasificar como basado en token de portador. Sin embargo, tenga en cuenta 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 de Authorization y usar el esquema de autenticación de Bearer .

Con respecto 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 honesto, no parece correcto y / o no vale la pena. El siguiente artículo ( Cookies vs Tokens: La guía definitiva ) puede ser una lectura útil sobre este tema, particularmente la sección de Protección XSS y XSRF .

Un último consejo, incluso si no necesita completar OAuth 2.0, recomendaría encarecidamente pasar su token de acceso dentro del encabezado de Authorization lugar de ir con encabezados personalizados . Si realmente son tokens de portador, siga las reglas de RFC 6750, de lo contrario, siempre puede crear un esquema de autenticación personalizado y aún usar ese encabezado.

Los encabezados de autorización son reconocidos y tratados especialmente por servidores proxy y HTTP. Por lo tanto, el uso de tales encabezados para enviar tokens de acceso a servidores de recursos reduce la probabilidad de fuga o almacenamiento no intencionado de solicitudes autenticadas en general, y especialmente encabezados de autorización.

(fuente: RFC 6819, sección 5.4.1 )