Décodeur JWT
Inspectez l’en-tête, le payload et l’expiration d’un JWT.
À propos de cet outil
Décodez un JSON Web Token pour lire son en-tête et ses claims. Les horodatages comme exp, iat et nbf s’affichent sous forme de dates lisibles, et vous voyez d’un coup d’œil si le jeton a expiré. La signature n’est pas vérifiée.
Mode d’emploi
- Collez un JSON Web Token. Un « Bearer » initial est supprimé automatiquement.
- Lisez l’en-tête et le payload décodés.
- Consultez le bandeau d’état et les claims de date pour savoir quand le jeton a été émis et quand il expire.
Questions
- Cet outil vérifie-t-il la signature ?
- Non. Il se contente de décoder le jeton. La vérification nécessite la clé secrète ou publique et doit se faire sur votre serveur. Ne faites jamais confiance à un jeton simplement parce qu’il se décode.
- Puis-je coller un vrai jeton ici sans risque ?
- Le décodage se fait entièrement dans votre navigateur et le jeton n’est jamais envoyé nulle part. Traitez néanmoins les jetons de production comme des mots de passe et préférez des jetons expirés ou de test quand c’est possible.
- Que signifient exp, iat et nbf ?
- exp indique quand le jeton expire, iat quand il a été émis, et nbf le moment avant lequel il ne doit pas être accepté. Ce sont tous trois des horodatages Unix en secondes.
- Tout le monde peut-il lire le contenu d’un JWT ?
- Oui. L’en-tête et le payload sont seulement encodés en Base64url, pas chiffrés. Ne mettez ni secrets ni données personnelles sensibles dans le payload d’un JWT.
- Pourquoi mon token a-t-il cinq parties au lieu de trois ?
- Un token composé de cinq parties séparées par des points est un JWE, un JSON Web Token chiffré défini dans la RFC 7516. Son payload ne peut pas être lu sans la clé de déchiffrement, donc ce décodeur signale une erreur. Un token avec seulement deux parties a généralement été tronqué lors de la copie : même un token non signé conserve un point final.
- Qu’est-ce que le kid dans le header d’un JWT ?
- kid est l’identifiant de clé. Il indique au vérificateur quelle clé utiliser quand l’émetteur en publie plusieurs, par exemple dans un document JWKS. C’est ce qui rend la rotation des clés possible : les nouveaux tokens sont signés avec une nouvelle clé, tandis que ceux signés avec l’ancienne restent valides jusqu’à leur expiration.
- Peut-on modifier le payload d’un JWT et continuer à l’utiliser ?
- Vous pouvez modifier le payload et le réencoder, mais la signature ne correspondra plus : un serveur correctement configuré rejettera donc le token. Si un token modifié est accepté, c’est que le serveur ne vérifie pas les signatures, une faille de sécurité grave qu’il faut signaler ou corriger immédiatement.
Qu’est-ce qu’un JWT et comment est-il structuré ?
Un JSON Web Token, défini dans la RFC 7519, est une chaîne compacte de trois parties séparées par des points : header, payload et signature. Le header indique comment le token est signé, avec une valeur alg comme HS256 ou RS256. Le payload contient les claims : de qui parle le token (sub), qui l’a émis (iss), à qui il est destiné (aud) et quand il expire (exp). Ces deux parties sont du JSON encodé en base64url.
La troisième partie est la signature, calculée sur les deux premières avec un secret ou une clé privée. Comme le header est un JSON qui commence par une accolade et un guillemet double, presque tous les JWT commencent par eyJ, ce qui permet de les repérer dans les journaux et les en-têtes de requête. Collez un token dans ce décodeur JWT pour voir le header et le payload formatés, avec les claims temporels affichés sous forme de dates.
Pourquoi mon JWT est-il refusé alors qu’il se décode ?
Un token qui se décode correctement peut tout de même être refusé, généralement avec un 401. La cause la plus courante est l’expiration : regardez le bandeau d’état, qui indique si exp est déjà dépassé. N’oubliez pas que exp est exprimé en secondes : un backend qui le compare à un temps JavaScript en millisecondes se trompera. Le décalage d’horloge entre serveurs compte aussi, c’est pourquoi la plupart des bibliothèques tolèrent une petite marge.
Si les dates semblent correctes, comparez les claims avec ce qu’attend le serveur. Un aud qui ne correspond pas à l’API, un iss inattendu ou un token d’un fournisseur d’identité de staging envoyé en production échouent tous à la validation. La vérification de signature échoue quand la clé est mauvaise, que le token a été modifié ou que l’alg du header n’est pas accepté par le serveur. Ce décodeur ne vérifie pas les signatures : il ne peut donc pas vous dire lequel de ces cas s’applique.
HS256 ou RS256 : quel algorithme JWT choisir ?
HS256 signe le token avec HMAC-SHA256 et un seul secret partagé. Chaque service qui vérifie les tokens a besoin de ce même secret, ce qui lui permet aussi d’en créer de nouveaux. C’est acceptable pour un seul backend, mais risqué avec de nombreux services. RS256 (RSA) et ES256 (ECDSA) utilisent plutôt une paire de clés : l’émetteur signe avec une clé privée, et tous les autres vérifient avec la clé publique, souvent publiée sur un endpoint JWKS.
Quel que soit votre choix, fixez l’algorithme autorisé côté vérification au lieu de faire confiance au champ alg du header. Un token dont alg vaut none ne porte aucune signature et doit toujours être rejeté. Gardez un exp court, quelques minutes plutôt que plusieurs jours, et utilisez des refresh tokens pour les sessions plus longues. Vous pouvez lire alg et kid dans le panneau En-tête ici, et vérifier n’importe quel horodatage avec le Convertisseur d’horodatage Unix.
Quelque chose ne fonctionne pas, ou un résultat semble faux ? Signaler un problème avec cet outil