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

Tengo un nuevo SPA con un modelo de autenticación sin estado utilizando 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.

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 usar 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 intentar 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 debe presentar una parte para tener 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 Authorizationencabezado HTTP y usar el Beareresquema de autenticación.

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 Authorizationencabezado en 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 )

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).

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.

JWT (JSON Web Tokens) : es solo un formato de token. Los tokens JWT son estructuras de datos codificados con 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 algunas restricciones 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/

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 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 está OAUTH provideren 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 authenticationpara JWT y OAUTH pero ninguno proporciona el mecanismo de autenticación. Sí, uno es un mecanismo de token y el otro es 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

Encuentra las principales diferencias entre JWT y OAuth

1. OAuth 2.0 define un protocolo y JWT define un formato de token.

2. OAuth puede usar JWT como formato de token o token de acceso, que es un token portador.

3. 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 manera 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é?

La pregunta es común, pero no es del todo razonable. JWT es un tipo de token, y OAuth es un marco que describe cómo dispensar tokens.

¿Qué queremos decir con "marco"? Solo la secuencia de solicitudes y respuestas, y los formatos de esos, que pueden y deben usarse para solicitar tokens. OAuthv2 describe "flujos" separados o tipos de concesión para diferentes escenarios, y tiene diferentes extensiones (como PKCE) para extender la seguridad de flujos particulares.

El resultado de una solicitud de token a través de una concesión OAuthV2 es ... un token. Esa cosa entonces se emplea como un "token de portador", lo que significa que cualquier parte que tenga el token puede presentarlo al hacer una solicitud de servicio API (por ejemplo, "¿cuál es el saldo de mi tarjeta de valor almacenado?"). Como token de portador, funciona como dinero en efectivo. Si lo está sosteniendo, puede usarlo. (Aunque a diferencia del dinero en efectivo, un token no es usarlo y perderlo. Quizás una mejor analogía es un boleto para viajar todo el día en el sistema de transporte público, o un boleto de todo el día en Disneyworld).

JWT es un tipo particular de token, y JWT se puede usar absolutamente como un token OAuth Bearer. De hecho, esta es la práctica más común. A la luz de eso, "JWT vs OAuth" es una comparación de manzanas y carritos de manzanas.

A menudo, las personas piensan que el "token OAuth" siempre implica un token opaco, una secuencia aleatoria de caracteres alfanuméricos que no contiene ningún significado inherente, que es otorgado por un dispensario de tokens OAuth, que luego puede ser validado solo por el mismo sistema dispensario OAuth. Pero este no es el único tipo de token OAuth. Una ficha opaca es un tipo de ficha; JWT se puede usar como un tipo diferente de token OAuth.

JWT, en contraste, no son opacos. El JWT no es un "puntero" o una referencia a la información. En realidad, contiene mucha información específica, que puede ser extraída e interpretada por cualquier parte que tenga el token. Debido a que el JWT contiene información real, un JWT puede ser grande; 300 bytes, 500 bytes o más, dependiendo de las afirmaciones contenidas en él, y el algoritmo utilizado para firmarlo. Cuando las personas dicen "JWT se autovalidan", lo que quieren decir es que cualquier titular de JWT puede abrirlo, validarlo y luego tomar decisiones de autorización en función de los reclamos presentados en él. Validar el JWT significa: verificar su estructura, decodificar la codificación base64, verificar que la clave sea correcta, verificar la firma, luego verificar que las reclamaciones requeridas estén presentes en el token, verificar la caducidad. No es una cosa simple más bien un proceso de varios pasos, pero, por supuesto, hay muchas bibliotecas en varios lenguajes de programación que ayudan con esto, y por supuesto existe la política VerifyJWT que lo ayuda a hacerlo dentro de un proxy API de Apigee Edge. El punto es que cualquier titular o receptor puede verificar una ficha. Debido a esto, decimos que JWT admite "Federación": cualquiera puede generar un token, y cualquiera puede leer y validar un token.

Reclamos personalizados. Tanto los tokens JWT como los OAuth opacos pueden llevar reclamos personalizados sobre el tema. seguridad. Ambas son fichas de portador. Ambos necesitan ser protegidos como secretos. vencimiento. Ambos pueden marcarse con una caducidad. Ambos se pueden actualizar. El mecanismo de autenticación o experiencia. Ambos pueden presentar la misma experiencia de usuario.

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 públicos y privados. 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