Décoder et inspecter les jetons JWT

Un JSON Web Token (JWT) est la chaîne que votre navigateur envoie pour prouver qui vous êtes après la connexion — et il est lisible par quiconque le détient. Ce n’est pas une faille du design ; c’est le design. Le vrai risque n’est pas de lire un jeton, c’est de le lire quelque part. Coller un jeton actif dans un site de décodage au hasard remet votre session à un serveur que vous ne contrôlez pas. Le JWT Decoder n’envoie rien — il décode l’en-tête, la charge utile et les revendications entièrement dans votre navigateur, et le dit d’emblée : la note de sécurité sous l’entrée indique « Decode localement dans le navigateur. La signature n’est pas verifiee. »

TL;DR

Un JWT n’est pas une enveloppe scellée. Ce sont trois parties Base64URL avec une signature au bout, et les deux premières sont du texte en clair déguisé.

Un JWT comporte trois parties — header.payload.signature, chacune séparée par un point. Les deux premières sont du JSON encodé en Base64URL.
Quiconque a le jeton peut le lire — l’en-tête et la charge utile se décodent en millisecondes, sans clé.
La signature prouve l’intégrité, pas la confidentialité — elle permet au serveur de confirmer que le jeton n’a pas été altéré. Elle ne masque pas le contenu.

Décodez localement, lisez ce que dit le jeton et ne traitez jamais la charge utile comme un endroit sûr pour les secrets.

Anatomie d’un JWT

Chaque JWT comporte exactement trois segments Base64URL, joints par des points :

<header>.<payload>.<signature>

Prenez le jeton d’exemple de l’outil (chargez-le avec le bouton Exemple) et regardez les deux premiers segments. Ils ressemblent à du bruit, mais chacun n’est que du JSON encodé en Base64URL. Décodés, ils se lisent :

Header — {"alg":"HS256","typ":"JWT","kid":"example-demo"}. Il déclare l’algorithme, le type de jeton et l’id de clé. Il indique au serveur comment vérifier, rien de secret.
Payload — {"iss":"example-app","sub":"demo-user","name":"홍길동","scope":"read write","iat":1704067200,"nbf":1704067200,"exp":4102444800}. Ce sont les revendications : des déclarations sur le jeton — qui l’a émis, pour qui, ce qu’il autorise et quand il expire.
Signature — demo-signature. Dans un vrai jeton, c’est une valeur cryptographique que le serveur calcule sur l’en-tête et la charge utile avec un secret ou une clé privée. L’exemple de l’outil livre volontairement un substitut.

L’en-tête et la charge utile sont les parties lisibles. La signature est la seule pièce que vous ne pouvez pas relire vers son entrée — et elle existe pour prouver que les deux autres n’ont pas été modifiées en transit, pas pour les garder privées. (Pour la moitié encodage de cette histoire, voir Encodage Base64 vs chiffrement — un JWT est un exemple pratique de « Base64 n’est pas un secret ».)

Revendications standards décodées

La charge utile est un sac de revendications — des paires clé/valeur convenues par convention. Celles enregistrées que vous rencontrerez presque à chaque fois :

iss (émetteur) — qui a émis le jeton, généralement une URL ou un identifiant.
sub (sujet) — de qui parle le jeton, typiquement un id d’utilisateur ou de compte.
aud (audience) — à qui le jeton est destiné. Un jeton frappé pour le service de facturation doit être rejeté par le service de profil.
exp (expiration) — le moment où le jeton cesse d’être valide, comme timestamp Unix. C’est la revendication la plus importante à vérifier.
iat (émis à) — quand le jeton a été créé.
nbf (pas avant) — le moment le plus tôt où le jeton est valide. Combiné avec iat, cela permet d’émettre des jetons légèrement en avance.

exp compte parce que les jetons sont des identifiants au porteur : quiconque en présente un valide entre. Des jetons courts et expirants limitent les dégâts si l’un est volé. Un jeton avec exp loin dans le futur est une clé de longue durée ; un jeton sans exp du tout est effectivement permanent. Lisez toujours l’expiration avant de faire confiance à ce qu’un jeton affirme.

Étape par étape : décoder un jeton

Le JWT Decoder s’exécute entièrement dans votre navigateur — le jeton ne quitte jamais votre appareil. Le déroulé :

Collez le jeton. Déposez une chaîne complète header.payload.signature dans la zone Entrée token JWT. Cliquez Exemple pour charger le jeton de démo intégré plutôt que de coller le vôtre.
Décodez. Cliquez Decoder. Le panneau de droite se remplit du résultat analysé. (Si vous modifiez l’entrée ensuite, la ligne d’état indique « L’entree a change. Decodez a nouveau pour actualiser. » pour que vous ne lisiez jamais une analyse périmée.)
Lisez le panneau Diagnostic. En haut il liste Algorithme, Type et Key ID tirés de l’en-tête, plus la taille en octets de chaque segment. C’est là que les jetons malformés ou à signature vide surgissent — un avertissement ici indique « Le token est expire. », « Le token n’est pas encore valide. » ou « Le segment de signature est vide. Decoder ne verifie pas les signatures. »
Vérifiez la chronologie des revendications. Le tableau dispose les revendications temporelles — exp, iat, nbf — chacun avec ses secondes brutes, la lecture ISO UTC et un Statut Actif, Passé ou Futur. Une ligne exp marquée Passé est un jeton expiré ; une ligne nbf marquée Futur signifie qu’il n’est pas encore valide.
Lisez les panneaux Header et Payload. Chacun est du JSON mis en forme avec un bouton Copier. C’est le contenu complet et décodé du jeton — émetteur, sujet, scopes, tout.
Copiez ce dont vous avez besoin. Utilisez Copier sur un seul panneau ou Tout copier pour un résumé textuel de l’en-tête, de la charge utile et de la signature ensemble. Utilisez Effacer pour tout vider.

Tout cela est une opération de lecture. L’outil n’appelle pas l’extérieur, ne vérifie pas la signature contre un émetteur et ne stocke pas le jeton — actualisez la page et il a disparu.

L’erreur critique

Parce qu’un JWT sert à l’authentification, les gens supposent que son contenu est secret. Il ne l’est pas. L’en-tête et la charge utile sont encodés en Base64URL, ce qui est de l’encodage, pas du chiffrement — réversible par quiconque en une étape, sans clé. (C’est le même piège que traiter Base64 comme sécurité ; voir Encodage Base64 vs chiffrement.)

Il y a une règle d’or : ne mettez jamais de secret dans la charge utile d’un JWT. Ni mots de passe, ni clés d’API, ni numéros de carte, ni identifiants d’aucune sorte. Si c’est dans la charge utile, supposez que c’est public — parce qu’une fois que le jeton quitte le serveur, n’importe qui sur le chemin peut le lire. La signature garantit que le jeton n’a pas été altéré ; elle ne garantit rien sur qui peut le voir.

Quand vous décodez un jeton et que la charge utile se lit correctement, cela signifie le format est honnête — pas que le contenu est privé. Concevez en conséquence : ne mettez dans la charge utile que ce dont le client a besoin, gardez les vrais secrets côté serveur et laissez les valeurs exp courtes faire la protection.

Vérifications associées

Décoder est la première question. Quelques voisins répondent au reste :

Vérifiez les parties Base64. Chaque segment est en Base64URL — confirmez l’aller-retour avec l’outil Base64. C’est aussi la façon dont vous prouvez que le contenu d’un JWT n’est pas caché : collez un segment, décodez-le, et le JSON revient directement.
Vérifiez les timestamps. exp, iat et nbf sont des secondes Unix. Transformez l’une en date lisible avec le Convertisseur de Timestamp pour voir exactement quand un jeton expire ou est devenu valide.
Intégrité via le hachage. La signature d’un JWT prouve qu’il n’a pas été altéré. Pour le même travail sur un fichier ou une chaîne quelconque, comparez des hachages avec le générateur de hachage et checksum — un condensé correspondant signifie « inchangé », sans clé échangée.

Questions fréquentes

Est-il sûr de décoder un JWT ?

Oui — décoder un JWT n’est que le décodage Base64URL de deux segments JSON. Cela révèle ce que le jeton dit déjà en clair à quiconque le détient ; cela n’affaiblit, n’expose et n’invalide pas le jeton. Ce qui n’est pas sûr, c’est où vous le décodez : coller un jeton actif dans un site inconnu peut faire fuir votre session. Décodez dans votre navigateur avec le JWT Decoder et le jeton ne quitte jamais votre appareil.

L’outil peut-il lire mon jeton ?

Non. Le JWT Decoder fonctionne entièrement côté client. Le jeton est analysé dans la mémoire de votre navigateur ; rien n’est envoyé, journalisé ni stocké sur un serveur. La note de sécurité sous l’entrée le dit directement : « Decode localement dans le navigateur. » Actualisez la page et l’entrée est effacée.

Que signifie « expiré » ici ?

Cela signifie que la revendication exp du jeton — son timestamp d’expiration — se situe dans le passé, donc un serveur vérificateur devrait le rejeter. Dans l’outil, un jeton expiré affiche exp comme Passé dans la chronologie des revendications et lève un avertissement « Le token est expire. » dans le panneau Diagnostic. « Expiré » concerne la validité, pas la lisibilité : le jeton se décode toujours très bien, il ne faut juste pas lui faire confiance.

Où le jeton est-il validé ?

Pas dans cet outil. Le JWT Decoder décode — il lit l’en-tête et la charge utile et affiche la chronologie des revendications. Il ne vérifie pas la signature contre la clé d’un émetteur, donc il ne peut pas vous dire qu’un jeton est authentique, seulement ce qu’il affirme. La vraie validation (vérifier la signature, exp, aud et l’émetteur) se fait sur le serveur qui a émis le jeton ou lui fait confiance. C’est pourquoi la note de sécurité est explicite : « La signature n’est pas verifiee. »