La question est courante, mais elle n'est pas tout à fait sensée. JWT est un type de jeton et OAuth est un framework qui décrit comment distribuer des jetons.
Qu'entendons-nous par «cadre»? Juste la séquence de demandes et de réponses, et les formats de celles-ci, qui peuvent et doivent être utilisés pour demander des jetons. OAuthv2 décrit des «flux» distincts ou des types d'octroi pour différents scénarios et possède différentes extensions (comme PKCE) pour étendre la sécurité de flux particuliers.
Le résultat d'une demande de jeton via une autorisation OAuthV2 est ... un jeton. Cette chose est ensuite utilisée comme un "jeton porteur", ce qui signifie que toute partie qui détient le jeton peut le présenter lors d'une demande de service api (par exemple, "quel est le solde sur ma carte de valeur stockée?"). En tant que jeton au porteur, cela fonctionne comme de l'argent liquide. Si vous le tenez, vous pouvez l'utiliser. (Bien que contrairement à l'argent comptant, un jeton ne soit pas utilisé et perdu. Peut-être une meilleure analogie est-elle un billet pour une journée dans le système de transport en commun ou un billet toute la journée à Disneyworld.)
JWT est un type particulier de jeton, et JWT peut absolument être utilisé comme jeton OAuth Bearer. En fait, c'est la pratique la plus courante. À la lumière de cela, "JWT vs OAuth" est une comparaison de pommes et de charrettes à pommes.
Souvent, les gens pensent que le "jeton OAuth" implique toujours un jeton opaque - une séquence aléatoire de caractères alphanumériques qui ne contient aucune signification inhérente - qui est accordé par un dispensaire de jetons OAuth, qui ne peut ensuite être validé que par ce même système de dispensaires OAuth. Mais ce n'est pas le seul type de jeton OAuth. Un jeton opaque est une sorte de jeton; JWT peut être utilisé comme un autre type de jeton OAuth.
Les JWT, en revanche, ne sont pas opaques. Le JWT n'est pas un "pointeur" ou une référence à l'information. Il contient en fait de nombreuses informations spécifiques, qui peuvent être extraites et interprétées par toute partie disposant du jeton. Étant donné que le JWT contient des informations réelles, un JWT peut être volumineux; 300 octets, 500 octets ou plus, selon les revendications qu'il contient et l'algorithme utilisé pour le signer. Lorsque les gens disent que «les JWT s'auto-valident», ce qu'ils veulent dire, tout détenteur du JWT peut l'ouvrir, le valider, puis prendre des décisions d'autorisation en fonction des revendications qui y sont présentées. Valider le JWT signifie: vérifier sa structure, décoder l'encodage base64, vérifier que la clé est correcte, vérifier la signature, puis vérifier que les revendications requises sont présentes dans le jeton, vérifier l'expiration. Ce n'est pas une chose simple, plutôt un processus en plusieurs étapes, mais bien sûr, il y a beaucoup de bibliothèques dans divers langages de programmation qui gèrent cela, et bien sûr il y a la politique VerifyJWT qui vous aide à le faire dans un proxy API Apigee Edge. Le fait est que tout détenteur ou récepteur peut vérifier un jeton. Pour cette raison, nous disons que JWT prend en charge la "Fédération" - n'importe qui peut générer un jeton, et n'importe qui peut lire et valider un jeton.
revendications personnalisées. Les jetons JWT et OAuth opaques peuvent porter des revendications personnalisées sur le sujet. Sécurité. Les deux sont des jetons au porteur. Les deux doivent être protégés en tant que secrets. expiration. Les deux peuvent être marqués d'une expiration. Les deux peuvent être rafraîchis. Le mécanisme ou l'expérience d'authentification. Les deux peuvent présenter la même expérience utilisateur.