Décoder en une étape
Un JSON Web Token ressemble à eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMifQ.signature : trois chaînes Base64url reliées par des points. Tout JWT commence par eyJ, car c'est ainsi que les caractères {" s'écrivent en Base64.
Collez le token dans l'outil ci-dessous. Le préfixe Bearer copié depuis un en-tête Authorization est accepté. Vous voyez le header et le payload en JSON mis en forme, les claims exp, iat, nbf et auth_time sous forme de dates dans votre heure locale avec une indication relative, et une ligne d'état qui indique si le token a expiré ou n'est pas encore valide. Pour contrôler la signature, saisissez le secret partagé ou la clé publique dans Secret ou clé publique (facultatif).
Essayez ici : Décodeur JWT
Ouvrir la page complète de l'outilLes trois parties d'un JWT
- Header : un petit objet JSON comme {"alg":"HS256","typ":"JWT"}. alg indique l'algorithme de signature ; kid, s'il est présent, identifie la clé utilisée, ce qui aide quand l'émetteur fait tourner ses clés.
- Payload : les claims, c'est-à-dire des affirmations sur l'utilisateur et le token, par exemple l'identifiant de l'utilisateur, l'émetteur, l'audience, les rôles et l'heure d'expiration. Toute personne qui détient le token peut les lire.
- Signature : calculée sur le header et le payload encodés avec un secret (HMAC) ou une clé privée (RSA ou courbe elliptique). Elle prouve que les deux premières parties n'ont pas été modifiées et qu'elles ont été émises par quelqu'un qui détient la clé.
- Un token en cinq parties au lieu de trois est un JWE chiffré. Son payload ne peut pas être lu sans la clé privée, et l'outil vous le signale quand vous en collez un.
Les claims courants et leur sens
La norme JWT (RFC 7519) enregistre quelques noms de claims courts. Les dates sont des valeurs NumericDate : des secondes depuis le 1er janvier 1970 UTC, pas des millisecondes. Confondre les deux est un bug classique, par exemple comparer exp avec Date.now() en JavaScript, qui renvoie des millisecondes.
| Claim | Nom | Signification |
|---|---|---|
| iss | Issuer (émetteur) | Qui a créé le token, souvent l'URL du fournisseur d'identité |
| sub | Subject (sujet) | Qui le token concerne, en général un identifiant d'utilisateur |
| aud | Audience | Quelle API ou application doit l'accepter |
| exp | Expiration time | Après ce moment, le token doit être refusé |
| nbf | Not before | Avant ce moment, le token n'est pas encore valide |
| iat | Issued at | Quand le token a été créé |
| jti | JWT ID | Identifiant unique, utilisé pour bloquer la réutilisation ou révoquer un token |
| auth_time | Authentication time | Quand l'utilisateur s'est réellement connecté (OpenID Connect) |
Décoder à la main ou dans le code
Le Base64url diffère du Base64 standard : il utilise le signe moins et le tiret bas au lieu de + et /, et le remplissage = est supprimé. La plupart des échecs de décodage viennent d'une partie de JWT passée directement à un décodeur Base64 standard. Remplacez le signe moins par + et le tiret bas par /, ajoutez des = jusqu'à ce que la longueur soit un multiple de 4, puis décodez.
En Python, base64.urlsafe_b64decode(part + "==") gère l'alphabet, et le remplissage en trop est toléré. Dans la console du navigateur, atob fonctionne une fois les deux caractères échangés, mais il renvoie les octets en Latin 1 : les noms accentués du payload, comme François ou Hélène, demandent un TextDecoder pour un UTF-8 correct. Des bibliothèques comme PyJWT, jsonwebtoken pour Node.js ou System.IdentityModel.Tokens.Jwt pour .NET décodent et vérifient en un seul appel ; en production, utilisez leur fonction de vérification, pas un raccourci qui se contente de décoder.
Pour un simple coup d'œil, un outil est plus rapide et évite de laisser le token dans l'historique de votre terminal.
Décoder n'est pas vérifier
Lire le payload vous dit ce que le token affirme ; cela ne prouve pas que ces affirmations sont vraies. N'importe qui peut créer un token avec "role": "admin" et l'encoder en Base64. Seule une signature valide, contrôlée avec la bonne clé, rend le contenu digne de confiance. Un serveur doit toujours vérifier avant d'utiliser le moindre claim.
Dans l'outil, les tokens HS256, HS384 et HS512 sont vérifiés avec le secret partagé. Les tokens RS, PS et ES sont vérifiés avec la clé publique de l'émetteur au format PEM, le bloc qui commence par BEGIN PUBLIC KEY. Si votre fournisseur d'identité publie ses clés uniquement sous forme de liste JWKS, convertissez d'abord en PEM la clé correspondante (celle dont le kid correspond au header). Le résultat affiche La signature est valide ou La signature ne correspond pas à la clé. Si vous collez une clé privée, l'outil vous demande la clé publique à la place.
Méfiez-vous de ces signaux d'alerte : alg réglé sur none (le token n'a aucune signature et l'outil le marque comme non signé), un algorithme inattendu (un serveur qui attend du RS256 ne doit jamais accepter un token HS256, c'est une attaque connue), et les tokens dont iss ou aud ne correspondent pas à votre système.
Résoudre les problèmes de tokens expirés ou invalides
- Token expiré : regardez la date exp dans la section Dates. Les access tokens ne vivent souvent que 5 à 60 minutes, c'est voulu ; l'application doit utiliser un refresh token pour en obtenir un nouveau.
- Pas encore valide : nbf ou iat est dans le futur, ce qui signifie en général que l'horloge du serveur et celle de l'émetteur diffèrent. Beaucoup de bibliothèques tolèrent un petit décalage de quelques secondes à quelques minutes ; corrigez l'horloge avec la synchronisation de l'heure.
- Cela ne ressemble pas à un JWT : le token a été tronqué, entouré de guillemets ou contient des espaces dus au copier-coller. Copiez-le à nouveau depuis l'en-tête ou le cookie d'origine.
- Impossible de lire le header ou le payload : une partie du token manque. Les tokens longs sont souvent coupés dans les logs.
- La signature ne correspond pas : mauvais secret, clé publique d'un autre environnement (préproduction au lieu de production), clé renouvelée, ou token modifié.
Manipuler les tokens en toute sécurité
Un access token valide fonctionne comme un mot de passe jusqu'à son expiration. Ne collez pas de tokens de production actifs dans des sites qui les envoient à un serveur, et ne les publiez pas dans des tickets ou des messageries. Ce décodeur fonctionne entièrement dans votre navigateur : le token n'est ni envoyé, ni journalisé, ni conservé.
Côté émetteur, gardez le payload léger et sans secrets. Comme tout le monde peut le lire, ne mettez jamais dans un JWT de mot de passe, de clé d'API ni de données personnelles que le client ne doit pas voir. Stockez l'identifiant de l'utilisateur et ses rôles, et cherchez tout le reste côté serveur.