Décodeur JWT
Collez un JSON Web Token pour lire son en-tête et son payload en JSON formaté, avec les dates d’expiration et d’émission affichées en clair et une indication sur la validité actuelle du jeton. Le décodage se fait entièrement dans votre navigateur, ce qui compte lorsque le jeton est un identifiant actif.
0 caractères · 0 mots · 0 lignes
0 caractères · 0 mots · 0 lignes
Fonctionne entièrement dans cet onglet du navigateur. Votre texte n’est jamais envoyé ni stocké.
Revendications enregistrées
Les sept noms de revendications définis dans la RFC 7519 §4.1. Toutes sont facultatives ; les heures sont exprimées en secondes depuis le 1970-01-01 UTC.
| Revendication | Signification |
|---|---|
iss | Émetteur : qui a créé et signé le jeton |
sub | Sujet : l’utilisateur ou l’entité concernée par le jeton |
aud | Audience : le destinataire prévu du jeton |
exp | Date d’expiration : rejeter le jeton après cet instant |
nbf | Pas avant : rejeter le jeton avant cet instant |
iat | Émis le : date de création du jeton |
jti | ID du JWT : identifiant unique, utilisé contre le rejeu |
Valeurs courantes de alg
| Valeur de alg | Signification |
|---|---|
HS256 | HMAC avec SHA-256 ; un secret partagé signe et vérifie |
RS256 | Signature RSA PKCS#1 v1.5 avec SHA-256 ; la clé privée signe, la clé publique vérifie |
PS256 | RSA-PSS avec SHA-256 |
ES256 | ECDSA sur la courbe P-256 avec SHA-256 ; signatures courtes |
EdDSA | Signatures Ed25519 ou Ed448 |
none | Jeton non signé ; les serveurs doivent le rejeter |
Ce que contient un JSON Web Token
Le JWT est défini par la RFC 7519 (mai 2015), qui suggère de le prononcer comme le mot anglais « jot ». La forme signée courante est composée de trois chaînes Base64url reliées par des points : header.payload.signature. L'en-tête (header) indique l'algorithme de signature dans alg, comme HS256 ou RS256, et souvent un identifiant de clé dans kid. Le payload contient des claims, des champs JSON tels que sub (l'utilisateur), iss (l'émetteur), aud (le destinataire prévu) et exp, nbf et iat, qui sont des dates exprimées en secondes depuis le 1er janvier 1970 UTC. Le décodeur convertit ces trois valeurs dans votre heure locale et en ISO 8601, et vous indique si le jeton a expiré, n'est pas encore valide ou se trouve dans sa période de validité.
Base64url est un encodage, pas un chiffrement : toute personne qui détient un jeton peut lire son payload, exactement comme le fait cette page. Ne placez jamais de mots de passe, de numéros de carte ou d'autres secrets dans les claims. Un jeton à cinq parties séparées par des points est un JWE, un jeton chiffré ; son contenu est illisible sans la clé, et le décodeur vous le signale. Un « Bearer » placé au début et copié depuis un en-tête Authorization est supprimé automatiquement.
Pourquoi la signature n’est pas vérifiée ici
La signature prouve que l'en-tête et le payload ont été produits par une personne détenant la clé et qu'ils n'ont pas été modifiés depuis. Pour la vérifier, il faut cette clé : le secret partagé pour les algorithmes HMAC comme HS256, ou la clé publique de l'émetteur pour RS256, ES256 ou EdDSA. Coller un secret de signature de production dans une page web est une mauvaise idée, et un décodeur qui prétendrait garantir un jeton sans clé donnerait une fausse impression de sécurité : cet outil affiche donc la signature sans la vérifier. Considérez ce que vous voyez comme une déclaration du jeton, pas comme un fait établi.
La vérification doit se faire sur votre serveur, avec une bibliothèque maintenue et l'algorithme attendu imposé. Deux erreurs historiques l'expliquent : accepter alg « none », ce qui permet à n'importe qui de forger un jeton non signé, et la confusion d'algorithme, où un serveur qui attend du RS256 est amené à vérifier une signature HS256 en utilisant la clé publique comme secret HMAC. Un décodeur sert au débogage : voir quels claims un fournisseur émet, repérer une audience incorrecte, ou comprendre qu'une session a échoué parce que exp est dépassé depuis une minute. Pour lire les segments Base64url bruts, utilisez le décodeur Base64.
Questions fréquentes
- Peut-on coller sans risque un vrai jeton d’accès dans un décodeur JWT ?
- Sur cette page, le jeton ne quitte jamais votre navigateur. Cependant, un jeton valide fonctionne comme un mot de passe jusqu'à son expiration : privilégiez des jetons expirés ou de test, et gardez les jetons actifs hors des captures d'écran et des conversations.
- Pourquoi mon jeton apparaît-il expiré alors qu’il vient d’être émis ?
- Vérifiez d'abord l'horloge de votre appareil. Certains émetteurs donnent aux jetons d'accès une durée de vie de quelques minutes seulement, et un jeton copié depuis un journal peut être plus ancien qu'il n'y paraît. Un exp écrit en millisecondes au lieu de secondes produit l'effet inverse et tombe des milliers d'années dans le futur.
- Quelqu’un peut-il modifier le payload de mon JWT ?
- Elle peut le modifier et le réencoder, mais la signature ne correspondra plus. Un serveur qui vérifie les signatures avec la bonne clé et le bon algorithme rejette le jeton altéré.
- Quelle est la différence entre JWS et JWE ?
- Un JWS (RFC 7515) est signé, comporte trois parties et peut être lu par tout le monde. Un JWE (RFC 7516) est chiffré, comporte cinq parties et seul le détenteur de la clé peut lire le payload.
- La déconnexion invalide-t-elle un JWT ?
- Pas à lui seul. Un JWT signé reste valide jusqu'à exp, sauf si le serveur tient une liste de refus ou consulte un enregistrement de session, ce qui explique pourquoi les jetons d'accès ont généralement une durée de vie courte.