À propos du décodeur JWT
Ce décodeur JWT gratuit lit un JSON Web Token et affiche son en-tête et sa charge utile sous forme de JSON formaté, avec les dates d'émission et d'expiration converties en dates lisibles.
Le décodage se fait dans votre navigateur — votre jeton n'est jamais envoyé. Ce n'est pas un détail : un JWT est généralement un identifiant actif, et coller le vôtre dans un site qui l'envoie ailleurs revient à céder tous les accès qu'il contient.
Cet outil décode un jeton. Il ne vérifie pas la signature — voyez plus bas pourquoi cette distinction compte.
Les trois parties d'un jeton
Un JWT est constitué de trois blocs de Base64url séparés par des points :
xxxxx.yyyyy.zzzzz
En-tête — quel algorithme a signé le jeton et de quel type il s'agit. Généralement deux champs : alg et typ.
Charge utile — les revendications (claims). Qui le jeton concerne, qui l'a émis, quand il expire, et tout ce que l'application y a mis : identifiant utilisateur, e-mail, rôles, permissions, locataire.
Signature — un contrôle cryptographique sur les deux premières parties, réalisé avec un secret ou une clé privée. Il prouve que le jeton n'a pas été modifié depuis son émission.
L'essentiel à comprendre : les deux premières parties ne sont pas chiffrées. Elles sont simplement encodées, et n'importe qui peut les lire. Collez un jeton dans cette page et son contenu apparaît instantanément. Le Base64url est un moyen de rendre des données transportables dans une URL ou un en-tête, pas un moyen de les cacher.
Ce que cela implique pour ce que vous mettez dans un jeton
Puisque la charge utile est lisible par quiconque détient le jeton, la règle en découle directement : ne mettez jamais rien de secret dans un JWT.
Ce qui n'a pas sa place dans une charge utile : mots de passe, clés d'API, données de carte bancaire, numéros d'identité nationale, informations médicales, tout ce qui relève de la réglementation sur la vie privée. Tout cela est lisible par l'utilisateur, par tout ce qui journalise la requête, et par quiconque obtient le jeton.
Ce qui y a sa place : un identifiant utilisateur, un rôle, une expiration, un émetteur, une audience — des identifiants et des revendications destinés à être vus par le système qui les reçoit.
La signature protège l'intégrité, pas la confidentialité. Elle garantit que personne n'a modifié le jeton. Elle n'empêche en rien de le lire.
Décoder n'est pas vérifier
C'est la distinction qui cause de vraies failles de sécurité, il vaut donc la peine d'être précis.
Décoder déballe le Base64url et vous montre le JSON. Cela ne demande aucune clé, n'importe qui peut le faire, et cela ne prouve absolument rien quant à l'authenticité du jeton.
Vérifier recalcule la signature à l'aide du secret ou de la clé publique et contrôle qu'elle correspond. Cela seul vous dit que le jeton a bien été émis par celui qu'il prétend et qu'il n'a pas été altéré.
Un jeton peut se décoder parfaitement et être un faux complet. N'importe qui peut fabriquer un JWT qui dit "role": "admin" et il s'affichera très bien ici — parce que l'afficher est tout ce qui se passe.
Cet outil ne vérifie délibérément pas, et c'est le choix sûr : la vérification exige le secret de signature, et coller votre secret de signature dans une page web serait bien plus dangereux que d'y coller un jeton. La vérification appartient à votre serveur, avec votre clé, en utilisant une bibliothèque appropriée.
La version historique de cette erreur est l'attaque alg: none. Les premières bibliothèques JWT honoraient un en-tête déclarant qu'aucun algorithme n'avait été utilisé et acceptaient le jeton sans vérification. Un attaquant pouvait modifier la charge utile, mettre alg à none, et entrer. Les bibliothèques modernes le refusent, mais c'est pourquoi vous devez toujours fixer l'algorithme attendu plutôt que de laisser l'en-tête vous le dire.
Lire les revendications standard
La plupart des noms de champs courts d'une charge utile sont des revendications enregistrées, au sens fixé :
- exp — date d'expiration. Après quoi le jeton doit être rejeté.
- iat — issued at, émis le. Quand il a été créé.
- nbf — not before, pas avant. Le jeton est invalide jusqu'à cette date.
- sub — sujet. Généralement l'identifiant utilisateur.
- iss — émetteur. Qui a créé le jeton.
- aud — audience. À quel service il est destiné.
- jti — identifiant du jeton, utilisé pour les listes de révocation.
exp, iat et nbf sont des horodatages Unix — des secondes depuis le 1er janvier 1970 — d'où leur apparence de nombre à dix chiffres dénué de sens. Cet outil les convertit en dates lisibles, ce qui est en général le moyen le plus rapide de répondre à la question qui vous a amené ici : *ce jeton a-t-il expiré ?*
Comment l'utiliser
- Collez votre JWT (la chaîne xxxxx.yyyyy.zzzzz)
- Lisez l'en-tête et la charge utile décodés ci-dessous
- Copiez l'une ou l'autre partie si vous en avez besoin
Bon à savoir
- Traitez un jeton comme un mot de passe. S'il est encore valide, quiconque le détient peut agir en tant que cet utilisateur. Ne collez pas de jetons actifs dans des outils qui les envoient, et ne les publiez pas dans un ticket ou une discussion.
- Les JWT sont difficiles à révoquer. Ils restent valides jusqu'à leur expiration, donc un jeton volé fonctionne jusque-là, sauf si vous maintenez une liste de blocage. C'est pourquoi des durées de validité courtes comptent.
- Bearer ne fait pas partie du jeton. Retirez ce préfixe d'un en-tête Authorization avant de décoder.
- Le Base64url n'est pas le Base64 standard. Il utilise - et _ au lieu de + et / et supprime généralement le remplissage =, d'où l'échec possible d'un bloc de JWT dans un décodeur Base64 ordinaire.
- Les décalages d'horloge causent des échecs déroutants. Un jeton peut vous sembler valide et être rejeté par un serveur dont l'horloge diffère d'une ou deux minutes.
- Un JWT n'est pas une session. Il transporte ses revendications avec lui, donc les changements de rôle d'un utilisateur ne prennent effet qu'à l'expiration du jeton.
Questions fréquentes
Un JWT est-il chiffré ?
Non. L'en-tête et la charge utile sont encodés en Base64url, ce qui les rend transportables dans une URL ou un en-tête HTTP mais ne les cache en rien. Quiconque détient le jeton peut lire chacune des revendications qu'il contient, comme le montre cette page. La signature protège le jeton contre la modification, pas contre la lecture.
Cet outil vérifie-t-il la signature ?
Non, et délibérément. La vérification exige le secret de signature ou la clé publique, et coller votre secret de signature dans une page web serait considérablement plus dangereux que d'y coller un jeton. La vérification appartient à votre serveur, avec une bibliothèque appropriée. Cet outil décode et vous montre le contenu, ce dont vous avez besoin pour déboguer.
Est-il sûr de coller mon jeton ici ?
Ici, oui — le décodage se fait entièrement dans votre navigateur et rien n'est transmis, vous pouvez donc vous déconnecter d'Internet et cela fonctionne toujours. Méfiez-vous des outils en général, cependant. Un JWT actif est un identifiant fonctionnel, et un site qui l'envoie à un serveur vient de recevoir tous les accès qu'il accorde.
Comment savoir si mon jeton a expiré ?
Regardez la revendication exp, un horodatage Unix en secondes. Cet outil la convertit en date lisible et vous dit directement si le moment est passé. Si un jeton vous semble valide mais qu'un serveur le rejette, vérifiez le décalage d'horloge — une différence d'une ou deux minutes entre machines suffit.
Que signifient sub, iss, aud et iat ?
Ce sont des revendications enregistrées au sens standard : sub est le sujet, normalement l'identifiant utilisateur ; iss est l'émetteur qui a créé le jeton ; aud est l'audience visée, c'est-à-dire quel service doit l'accepter ; iat est la date d'émission. Avec exp et nbf, elles couvrent le qui, le où et le quand.
Pourquoi mon JWT échoue-t-il dans un décodeur Base64 ordinaire ?
Parce qu'un JWT utilise le Base64url, une variante qui remplace + par - et / par _ et supprime généralement le remplissage =. Ces substitutions existent pour que la valeur soit utilisable sans risque dans une URL. Remettre les caractères d'origine permet de la décoder dans un outil Base64 standard.
Puis-je modifier la charge utile d'un JWT ?
Vous pouvez en changer le texte, mais le résultat sera rejeté par tout serveur correctement implémenté, car la signature ne correspond plus au contenu modifié. C'est précisément à cela que sert la signature. Les jetons sont réémis par le service qui les signe, pas modifiés à la main.
Outils connexes
- Encoder / décoder en Base64 — l'encodage dans lequel les trois blocs sont écrits
- Formateur JSON — mettre en forme et inspecter la charge utile décodée
- Générateur de hachage — les fonctions de hachage qui sous-tendent la signature
