Décodeur JWT
Décodez l'en-tête et la charge utile d'un JSON Web Token et vérifiez son expiration, dans votre navigateur. Aucune signature n'est vérifiée ni envoyée.
Cette page a été traduite de l'anglais avec l'aide de l'IA, puis vérifiée par rapport à l'original. Lire la version anglaise
- Gratuit — Aucune inscription requise
- Instantané — Les résultats s'affichent au fur et à mesure
- Privé — Traité dans votre navigateur
Un JSON Web Token (JWT) se compose de trois segments encodés en Base64URL et reliés par des points : un header qui décrit l’algorithme, un payload qui porte les claims, et une signature calculée sur les deux premiers. Le header et le payload ne sont pas chiffrés, seulement encodés : quiconque détient un jeton peut donc les lire. C’est exactement ce que fait cet outil, et rien de plus.
Comment ça marche
Collez un jeton. L’outil le découpe au niveau des deux points, décode chacun des deux premiers segments depuis le Base64URL (l’alphabet avec - et _, sans padding, comme l’exige la RFC 7515) vers de l’UTF-8, puis analyse le résultat comme du JSON. Le header et le payload s’affichent mis en forme, chacun avec son bouton de copie. Le troisième segment est affiché tel quel, puisqu’il s’agit des octets bruts de la signature et non de JSON.
Si le payload contient les claims temporels standard, ils sont présentés sous forme de dates locales : iat (émis le), nbf (non valide avant) et exp (expire le), tous exprimés en timestamps Unix en secondes. Le badge en haut compare exp à l’horloge de votre appareil ; un jeton est signalé comme expiré dès que l’heure actuelle atteint ou dépasse cet instant. Aucun badge n’apparaît en l’absence de claim exp numérique.
Les échecs les plus courants : un jeton qui n’a pas le bon nombre de segments (un JWE, qui est chiffré, en compte cinq), un segment qui n’est pas du Base64URL valide, ou un segment qui, une fois décodé, n’est pas du JSON. Chaque cas donne lieu à un message précis.
Le décodage a lieu dans votre navigateur et le jeton n’est jamais transmis. Un jeton reste pourtant un identifiant au porteur (bearer) : quiconque le possède peut agir au nom de son sujet jusqu’à son expiration. Décodez de préférence des jetons issus d’un environnement de test, et ne collez jamais un secret de signature ou une clé privée dans une page web, quelle qu’elle soit.
Ce que signifie « non vérifiée »
La signature prouve que le jeton a été émis par le détenteur de la clé de signature et qu’il n’a pas été modifié depuis. La vérifier suppose de disposer de la clé : le secret partagé pour les algorithmes HMAC comme HS256, ou la clé publique de l’émetteur pour RS256, ES256 et les autres algorithmes asymétriques. Cet outil n’a ni l’un ni l’autre ; il ne peut donc pas vous dire si un jeton est authentique. Un jeton qui se décode sans erreur et n’a pas expiré peut très bien être forgé, révoqué ou destiné à une autre audience.
La vérification doit se faire côté serveur, avec une clé récupérée sur l’endpoint JWKS de l’émetteur et un header alg confronté à une liste blanche. Accepter l’algorithme que le header annonce, quel qu’il soit, est la vulnérabilité JWT classique : un attaquant met alg à none, ou remplace un jeton RSA par un jeton HMAC signé avec la clé publique.
Lire les claims
Au-delà des claims temporels, repérez iss (qui l’a émis), sub (qui il concerne), aud (qui doit l’accepter) et jti (un identifiant unique, utile pour la révocation). Les access tokens délivrés par les serveurs OAuth 2.0 ajoutent généralement scope ou roles ; les ID tokens d’OpenID Connect ajoutent des champs de profil comme email et name, ainsi que nonce. Les claims personnalisés sont fréquents, mais chaque octet du payload voyage avec chaque requête : plus un jeton est léger, mieux c’est.
Équivalent en ligne de commande
jq peut décoder directement le payload, à condition de compléter d’abord le segment avec du padding jusqu’à un multiple de quatre caractères :
TOKEN='eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDAwMDAwMDB9.sig'
printf '%s' "$TOKEN" | cut -d. -f2 | tr '_-' '/+' | awk '{ while (length($0) % 4) $0 = $0 "="; print }' | base64 -d | jq .Pour aller plus loin
Sécuriser des API REST avec JWT traite de l’émission, de la validation et de la rotation des jetons, y compris l’attaque par confusion d’algorithme évoquée plus haut. Les jetons eux-mêmes proviennent des flux décrits dans OAuth 2.0, et les ID tokens en particulier d’OpenID Connect. Le convertisseur de timestamps convertit toute valeur de claim que le décodeur n’affiche pas déjà sous forme de date, et le générateur de hash montre la primitive SHA-256 sur laquelle reposent les signatures HS256.
FAQ
- Cela vérifie-t-il la signature du JWT ?
- Non — cet outil ne décode que l'en-tête et la charge utile, ce qui ne nécessite aucun secret. Vérifier une signature nécessite le secret de signature ou la clé publique de l'émetteur, qui ne devraient jamais être collés sur un site web.
- Pourquoi indique-t-il que mon token est expiré ?
- La revendication exp de la charge utile est un timestamp Unix indiquant quand le token cesse d'être valide. Si l'heure actuelle dépasse ce moment, le token est expiré, que la signature soit par ailleurs valide ou non.
- Mon token est-il envoyé quelque part ?
- Non. Le décodage s'effectue entièrement dans votre navigateur.