Décodeur JWT
Lisez l’en-tête et les revendications d’un jeton et voyez ce qu’il dit sur lui-même. Décodage, pas vérification.
Décoder n’est pas vérifier. Les deux segments lisibles d’un JWT ne sont que du Base64 : n’importe qui peut les lire et n’importe qui peut les écrire. Seule la signature rend un jeton digne de confiance, et la vérifier exige la clé. Cette page n’a pas la clé, ne vous la demande pas, et n’affirme rien quant à l’authenticité du jeton.
Un préfixe « Bearer » est retiré automatiquement. Rien de ce que vous collez ne quitte cette page.
Trois segments, dont un seul compte
Un JWT, ce sont trois chaînes en base64url réunies par des points. Les deux premières sont du JSON que vous pouvez lire ; la troisième est une signature portant sur les deux premières.
eyJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiIxMjM0In0 . 4fXK...
header payload signatureL’en-tête indique quel algorithme l’a signé. La charge utile porte les claims. Ni l’un ni l’autre ne sont chiffrés — le base64 est un encodage de transport, pas une dissimulation, et quiconque détient le jeton peut lire les deux en une seconde.
La signature est la seule partie qui fasse un travail de sécurité. Elle prouve que les deux premiers segments ont été produits par quelqu’un détenant la clé de signature et n’ont pas été modifiés depuis. Sans la vérifier, un JWT n’est qu’un fichier texte qui se décrit lui-même, avec pas plus d’autorité que n’importe quelle autre chaîne envoyée par un client.
C’est pourquoi cette page ne vous dira pas qu’un jeton est valide
La vérification exige la clé, et il n’existe aucune version de « collez votre secret de signature dans une page web » qui soit un bon conseil. Ce que fait l’outil à la place, c’est rapporter ce que le jeton dit de lui-même : s’il a expiré, si son heure d’entrée en vigueur est arrivée, si l’algorithme est symétrique ou asymétrique, et s’il prétend n’avoir besoin d’aucune signature.
alg:none, et pourquoi le cas est instructif
La spécification autorise "alg": "none" — un jeton sans signature. L’attaque s’écrit toute seule : prenez un jeton légitime, modifiez la charge utile pour affirmer ce qui vous chante, mettez l’algorithme à none, supprimez la signature et envoyez.
Une bibliothèque qui lit l’algorithme dans l’en-tête et fait ce qu’il dit acceptera cela. C’est l’attaquant qui a choisi la politique de vérification, parce que cette politique se trouvait dans la partie du message qu’il contrôle.
La variante voisine est la confusion d’algorithmes. Un serveur qui vérifie du RS256 possède la clé publique, laquelle n’est pas secrète. Changez l’en-tête en HS256 — un algorithme symétrique — et signez avec cette clé publique en guise de secret partagé. Une bibliothèque naïve emploie le même matériel de clé dans les deux cas, et le jeton forgé est validé.
Les deux se corrigent de la même façon, et c’est un principe général à emporter ailleurs : c’est au vérificateur d’énoncer quels algorithmes il accepte, plutôt que de le demander au jeton.
Ce qui déraille vraiment en production
| Symptôme | Cause habituelle |
|---|---|
| Rejeté juste après émission | Décalage d’horloge. Le iat ou le nbf est en avance de quelques secondes sur l’horloge du vérificateur. Prévoyez une petite tolérance. |
| Fonctionne en local, échoue une fois déployé | Clé de signature différente selon l’environnement — un jeton de préproduction envoyé en production. |
| Signature valide, jeton tout de même rejeté | Le claim aud ou iss ne correspond pas à ce que ce service attend. |
| Fonctionne, puis s’arrête en pleine session | Expiration. Les jetons de courte durée réclament un mécanisme de renouvellement, et c’est le plus souvent la pièce manquante. |
| Les requêtes échouent avec des en-têtes trop volumineux | Le jeton a dépassé la limite. La plupart des serveurs plafonnent les en-têtes autour de 8 Ko, et les navigateurs plafonnent un cookie à 4 Ko. |
Le problème de la révocation
La raison d’employer un JWT, c’est que la vérification ne demande aucune consultation de base de données — le jeton porte sa propre preuve. C’est aussi exactement pour cela qu’on ne peut pas le révoquer. Rien n’est consulté au moment de la vérification : il n’existe donc nulle part où noter qu’un jeton doit cesser de fonctionner.
Les options, dont aucune n’est gratuite :
- Expiration courte et jetons de renouvellement. La réponse standard. Les jetons d’accès vivent quelques minutes, les jetons de renouvellement sont vérifiés en base et peuvent être révoqués.
- Une liste de refus. Vérifier le
jtide chaque jeton auprès d’un magasin de jetons révoqués — ce qui réintroduit précisément la consultation que le format devait éviter. - Faire tourner la clé de signature. Cela invalide tous les jetons d’un coup, y compris ceux de tout le monde.
Si la révocation immédiate de sessions individuelles vous importe plus que la vérification sans état, un identifiant de session opaque adossé à un magasin est la conception la plus simple — et elle est sous-estimée.
À voir aussi
Les trois segments sont du Base64 compatible URL, sans remplissage — d’où l’échec fréquent d’un segment dans un décodeur strict. Une fois décodées, les deux parties lisibles sont du JSON. Et pour l’identifiant que le jeton remplace, le vérificateur de robustesse couvre l’autre bout de la connexion.
Questions sur les JWT
Le décodage d'un JWT le vérifie-t-il ?
Non, et la distinction réside dans l’ensemble du modèle de sécurité. L'en-tête et la charge utile sont en base64url — leur lecture ne nécessite rien. La vérification signifie recalculer la signature avec la clé et comparer, ce qui prouve que le jeton a été émis par celui qui détient cette clé et n'a pas été modifié depuis. Un décodeur sans clé peut vous dire ce que prétend un jeton ; seule la vérification vous dit si vous devez le croire.
Est-il sécuritaire de coller un vrai token dans un site Web ?
Dans cette page, oui : le décodage s'effectue dans votre navigateur et rien n'est transmis. Mais l’instinct derrière cette question est bon et mérite d’être gardé. Un JWT est généralement un identifiant actif : toute personne qui le détient peut agir en votre nom jusqu'à son expiration. Un décodeur qui le publie sur un serveur a bénéficié d'une session de travail. Vérifiez où un outil fait son travail avant d’y coller un jeton de production.
Puis-je mettre des secrets dans une charge utile JWT ?
Non. La charge utile est signée et non chiffrée : elle est lisible par toute personne détenant le jeton, y compris l'utilisateur auquel il a été émis. La signature garantit que le contenu n'a pas été modifié ; cela ne fait rien pour les cacher. Si vous avez réellement besoin d'une charge utile confidentielle, c'est JWE, une spécification différente et considérablement plus complexe. En pratique, la meilleure réponse est généralement de conserver la partie sensible sur le serveur et de mettre un identifiant dans le token.
Quelle est la vulnérabilité alg:none ?
La spécification JWT autorise un « alg » de « none », ce qui signifie un jeton non signé. L'attaque consiste à prendre un jeton valide, à modifier la charge utile pour revendiquer l'administrateur, à définir alg sur none et à supprimer la signature. Une bibliothèque qui fait confiance au champ d'algorithme de l'en-tête le validera — le jeton lui-même précisait qu'aucune vérification n'était requise. Toutes les bibliothèques majeures ont été corrigées, mais la leçon est généralisée : le serveur doit décider quels algorithmes il accepte, plutôt que de laisser le jeton en nommer un.
Comment puis-je révoquer un JWT avant son expiration ?
En grande partie, vous ne le pouvez pas, et c’est le commerce que fait le format. Un JWT est vérifiable sans recherche dans la base de données, ce qui le rend rapide – et c'est aussi pourquoi rien consulté au moment de la vérification ne sait que vous souhaitiez sa révocation. Les réponses réalisables sont des délais d'expiration courts avec des jetons d'actualisation, une liste de refus d'identifiants révoqués vérifiés à chaque demande (qui réintroduit la recherche que vous évitiez) ou une rotation de la clé de signature pour tout invalider en même temps.
Pourquoi mon token est-il rejeté alors qu’il semble valide ?
Après l'expiration, les causes habituelles sont un décalage d'horloge entre l'émetteur et le vérificateur, une réclamation du public ou de l'émetteur qui ne correspond pas à ce que le serveur attend, ou le jeton ayant été signé avec une clé différente de celle que détient le vérificateur - généralement un jeton intermédiaire utilisé contre la production. Le décodeur ci-dessus signale les problèmes de synchronisation qu'il peut détecter ; l'audience et les discordances clés dont seul le serveur peut vous informer.
Dernière vérification . Vous avez repéré quelque chose de dépassé ? Dites-le-nous.