Décodeur JWT

À propos des JWT

Un JSON Web Token regroupe un en-tête, une charge utile et une signature en trois segments encodés en Base64URL séparés par des points. L'en-tête et la charge utile ne sont que du JSON encodé, lisible par n'importe qui, tandis que la signature prouve que le jeton n'a pas été altéré.

Le champ alg de l'en-tête nomme l'algorithme de signature, mais comme l'en-tête n'est que du JSON décodé et non vérifié, un client ne peut pas lui faire confiance pour affirmer quoi que ce soit de vrai — une classe connue de vulnérabilité JWT consiste, pour un attaquant, à passer alg à « none » et à retirer la signature, en espérant qu'un vérificateur négligent accepte un jeton non signé. Une vérification réelle doit contrôler la signature avec un algorithme et une clé précis, choisis par le serveur vérificateur lui-même, jamais lus dans le jeton. Les claims exp et iat du payload sont des horodatages Unix (secondes depuis l'epoch, pas des millisecondes) — associez cet outil au Convertisseur d'horodatage pour les lire comme des dates calendaires.

Où vous le rencontrerez

• Examiner un jeton d'accès ou d'identité émis par un fournisseur OAuth ou OIDC
• Déboguer pourquoi un jeton n'a pas un claim attendu
• Vérifier l'expiration ou l'émetteur d'un jeton sans écrire de code
• Comprendre ce qu'une API ou bibliothèque tierce met réellement dans ses jetons

Questions fréquentes

Le décodage vérifie-t-il la signature ?
Non — cela ne fait que décoder l'en-tête et la charge utile pour que vous puissiez les lire. La signature n'est pas vérifiée, donc un jeton décodé ne prouve pas qu'il est authentique ou non expiré.

Puis-je faire confiance aux claims d'un jeton que je n'ai pas vérifié ?
Pas pour des décisions de sécurité. N'importe qui peut créer un JWT avec des claims arbitraires ; seule une signature vérifiée par rapport à la clé de l'émetteur rend le contenu fiable.

Le jeton que je colle ici est-il stocké ?
Non. Le décodage se fait entièrement pour cette seule requête ; rien n'est journalisé ni conservé.

Peut-on faire confiance au champ alg de l'en-tête ?
Pas à lui seul. L'en-tête est du JSON non vérifié et contrôlable par un attaquant, du point de vue de quiconque lit un jeton brut — une attaque JWT connue consiste à passer alg à « none » et à retirer entièrement la signature, en espérant qu'un vérificateur faisant aveuglément confiance à l'en-tête l'accepte comme valide. Un code de vérification correct fixe en dur l'algorithme et la clé attendus et ne tire jamais cette décision du jeton lui-même. Cet outil ne fait que décoder pour la lecture ; il ne prend aucune décision de confiance.