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.