Comment utiliser le décodeur JWT
- Collez un JSON Web Token, la longue chaîne qui suit généralement
Authorization: Bearer. - L’en-tête et la charge utile (payload) sont décodés et affichés en JSON formaté.
- Les claims temporels comme
exp,iatetnbfsont convertis en dates lisibles, pour que vous voyiez d’un coup d’œil si le jeton a expiré.
Anatomie d’un JWT
Un JSON Web Token, défini par la RFC 7519, est un moyen compact de transmettre des claims (revendications) entre plusieurs parties. La forme signée courante (JWS) comporte trois parties séparées par des points :
header.payload.signature
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMifQ.<signature>- En-tête (header) : du JSON qui décrit le jeton, principalement l’algorithme de signature.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9se décode en{"alg":"HS256","typ":"JWT"}. - Charge utile (payload) : du JSON qui contient les claims, c’est-à-dire les affirmations sur l’utilisateur ou la session.
- Signature : calculée sur l’en-tête et la charge utile encodés avec un secret (HMAC, par ex. HS256) ou une clé privée (par ex. RS256, ES256).
Chaque partie est encodée en base64url, l’alphabet Base64 compatible avec les URL, sans remplissage. C’est pourquoi les jetons contiennent - et _, et pourquoi les JWT commencent presque toujours par eyJ : c’est ainsi que s’encode le {" d’ouverture d’un objet JSON lorsqu’il est suivi d’un nom de clé typique en minuscules. Vous pouvez explorer l’encodage lui-même avec l’encodeur Base64.
Claims enregistrés
| Claim | Nom | Signification |
|---|---|---|
iss | Émetteur (Issuer) | Qui a créé et signé le jeton. |
sub | Sujet (Subject) | La personne ou l’entité concernée par le jeton, généralement un identifiant utilisateur. |
aud | Audience | Le ou les services auxquels le jeton est destiné. |
exp | Date d’expiration (Expiration time) | Timestamp Unix après lequel le jeton doit être rejeté. |
nbf | Pas avant (Not before) | Timestamp Unix avant lequel le jeton n’est pas encore valide. |
iat | Émis le (Issued at) | Timestamp Unix de création du jeton. |
jti | Identifiant JWT (JWT ID) | Identifiant unique, utile pour empêcher le rejeu. |
Tous ces claims sont facultatifs dans la RFC 7519 ; ce sont les applications qui décident lesquels elles exigent. Les claims temporels sont exprimés en secondes, pas en millisecondes ; le convertisseur de timestamp Unix explique la différence.
Pièges courants
Décoder n’est pas vérifier
N’importe qui peut décoder un JWT ; c’est exactement ce que fait cet outil. Le décodage vous dit ce qu’un jeton affirme, pas si ces affirmations sont authentiques. Un serveur doit vérifier la signature avec la bonne clé et contrôler exp, nbf, iss et aud avant de se fier au contenu de la charge utile.
La charge utile n’est pas secrète
Un JWT signé est lisible par quiconque le détient. N’y mettez pas de mots de passe, de données personnelles que vous ne voudriez pas exposer au client, ni de secrets internes. Si le contenu doit rester confidentiel, utilisez un JWT chiffré (JWE) ou gardez les données côté serveur.
alg: none et confusion d’algorithme
Les spécifications JOSE définissent une valeur "alg": "none" pour les jetons non sécurisés à signature vide. Une bibliothèque qui se fie à l’en-tête du jeton lui-même pourrait accepter un jeton falsifié comme celui-ci :
{"alg": "none", "typ": "JWT"}
{"sub": "admin"}
(signature vide)Une attaque voisine fait passer un jeton RS256 en HS256 afin que la clé publique soit utilisée à tort comme secret HMAC. La parade est la même dans les deux cas : configurez les algorithmes autorisés sur le serveur et ne laissez jamais le jeton choisir.
Conseils
- Donnez aux jetons d’accès une durée de vie courte et utilisez des jetons de rafraîchissement pour les sessions plus longues.
- Tolérez un léger décalage d’horloge (par exemple une minute) lorsque vous vérifiez
expetnbfentre plusieurs serveurs. - Utilisez une bibliothèque JWT bien maintenue plutôt que d’analyser et de vérifier les jetons à la main.
Questions fréquentes
Cet outil peut-il vérifier la signature d’un JWT ?
La vérification nécessite le secret ou la clé publique de l’émetteur et doit se faire dans votre backend. Cet outil sert à inspecter l’en-tête et les claims d’un jeton pendant le débogage.
Pourquoi mon jeton apparaît-il comme expiré ?
Le claim exp est antérieur à l’heure actuelle de votre appareil. Vérifiez que votre horloge est juste et que l’émetteur a bien écrit exp en secondes.
Les JWT sont-ils chiffrés ?
Les JWT signés (JWS), de loin les plus utilisés, sont seulement encodés et signés : n’importe qui peut donc les lire. Les JWT chiffrés (JWE) comportent cinq parties au lieu de trois.
Puis-je coller mon jeton ici sans risque ?
Le décodage se fait localement et rien n’est transmis. En règle générale, évitez de coller des jetons de production actifs dans un outil en ligne que vous n’avez pas examiné.
Mis à jour