Quelle est la différence entre JWT et Bearer Token?
J'apprends quelque chose à propos de l'autorisation comme Basic, Digest, OAuth2.0, JWT et Bearer Token.
Maintenant j'ai une question.
Vous savez que les JWT sont utilisés comme un Access_Token dans la norme OAuth2.0. JWT apparaît à la RFC 7519 et le porteur est à la RFC 6750.
Par exemple, le porteur:
Authorization: Bearer <token>
J'avais l'habitude d'envoyer un jeton au serveur par AJAX ou d'ajouter un jeton à la chaîne de requête de l'URL. Je sais qu'un jeton peut également être envoyé en l'ajoutant à un en-tête de requête. Cela signifie-t-il que le jeton doit être ajouté à l'en-tête du support d'autorisation?
Pourriez-vous s'il vous plaît me dire la relation entre JWT et Bearer Token? Merci beaucoup.
JWT est une norme de codage pour les jetons qui contient une charge de données JSON pouvant être signée et chiffrée.
JWT peut être utilisé pour beaucoup de choses, parmi celles-ci sont des jetons de porteur, c’est-à-dire une information que vous pouvez présenter à un service qui, du fait que vous l’avez (vous êtes le "porteur"), vous donne accès à quelque chose.
Les jetons de support peuvent être inclus dans une requête HTTP de différentes manières, l'une d'entre elles (probablement la préférée) étant l'en-tête Authorization. Mais vous pouvez également le définir dans un paramètre de requête, un cookie ou le corps de la requête. C'est principalement entre vous et le serveur auquel vous essayez d'accéder.
Réponse courte
Les JWT sont un moyen pratique pour encoder et vérifier revendications.
Un jeton porteur est simplement une chaîne, potentiellement arbitraire, utilisée pour l'autorisation.
Contexte (heure du conte)
Il y a quelques années, avant la révolution JWT, un <token> n'était qu'une chaîne sans signification intrinsèque, par exemple. 2pWS6RQmdZpE0TQ93X. Ce jeton a ensuite été recherché dans une base de données contenant les réclamations pour ce jeton. L'inconvénient de cette approche est qu'un accès à la base de données (ou un cache) est requis chaque fois que le jeton est utilisé.
JWTs encodent et vérifient (par la signature) leur propre réclamations. Cela permet aux gens d'émettre des JWT de courte durée qui sont sans état (lire: autonome, ne dépend de personne d'autre). Ils n'ont pas besoin de frapper la base de données. Cela réduit la charge de base de données et simplifie l'architecture des applications, car seul le service qui émet les fichiers JWT doit craindre de toucher la couche de base de données/persistance (le refresh_token que vous avez probablement rencontré).