Choisir la langue

Décodeur JWT

Décodez et inspectez vos jetons JWT dans le navigateur : en-tête, charge utile et revendications affichés en JSON lisible, avec vérification de l'expiration.

Mehmet Demiray Publié Mis à jour
Partager
Convertir les revendications exp, iat et nbf en dates lisibles

Qu'est-ce qu'un jeton JWT

Un JWT, ou jeton web JSON, est un format compact qui transporte des informations vérifiables entre deux parties. On le rencontre surtout dans l'authentification : après connexion, un serveur émet un jeton que le client renvoie à chaque requête pour prouver son identité.

Un JWT se compose de trois parties séparées par des points : l'en-tête, la charge utile et la signature. Visuellement, cela ressemble à xxxxx.yyyyy.zzzzz. Les deux premières parties sont simplement encodées en Base64URL, donc lisibles par quiconque possède le jeton.

C'est là un point essentiel : un JWT standard n'est pas chiffré, seulement signé. La signature garantit que le contenu n'a pas été altéré, mais elle ne le cache pas. Ce décodeur vous permet d'inspecter instantanément ces parties pour comprendre ce qu'un jeton contient réellement, sans avoir à le décortiquer à la main.

La structure d'un JWT en détail

Décomposer un jeton aide à comprendre ce qu'il transporte. Chacune des trois sections joue un rôle distinct et complémentaire.

Partie Contenu Encodage
En-tête algorithme et type Base64URL
Charge utile revendications Base64URL
Signature preuve d'intégrité binaire signé

L'en-tête précise l'algorithme de signature, par exemple HS256 ou RS256, ainsi que le type de jeton. La charge utile contient les revendications, c'est-à-dire les données transmises : identifiant de l'utilisateur, rôle, dates d'émission et d'expiration.

La signature, enfin, est calculée à partir de l'en-tête, de la charge utile et d'une clé secrète. Elle ne peut être recréée que par celui qui détient cette clé, ce qui permet de détecter toute modification. Si le contenu encodé est altéré, la signature ne correspond plus et le jeton est rejeté lors de la vérification côté serveur.

Lire les revendications standard

La charge utile d'un JWT contient des revendications, dont certaines sont normalisées et reviennent dans la plupart des jetons. Les reconnaître facilite grandement le débogage d'un système d'authentification.

Voici les revendications enregistrées les plus courantes :

Revendication Signification
iss émetteur du jeton
sub sujet, souvent l'identifiant utilisateur
exp date d'expiration
iat date d'émission
aud destinataire prévu

Les dates exp et iat sont exprimées en secondes écoulées depuis le 1 janvier 1970, au format temps Unix. Le décodeur les convertit en dates lisibles et signale si le jeton est expiré.

À côté de ces champs standard, un jeton peut transporter des revendications personnalisées propres à une application, comme un rôle ou des permissions. Inspecter ces valeurs aide à comprendre pourquoi un utilisateur obtient ou se voit refuser un accès donné, ce qui accélère considérablement le diagnostic.

Décoder n'est pas vérifier

Une distinction cruciale échappe souvent aux développeurs débutants : décoder un JWT et le vérifier sont deux opérations radicalement différentes. Cet outil décode, il ne valide pas la signature.

Le décodage se contente de transformer les parties Base64URL en JSON lisible. Aucune clé n'est requise, et n'importe qui peut le faire. C'est pratique pour inspecter le contenu, mais cela ne prouve rien quant à l'authenticité du jeton.

La vérification, elle, recalcule la signature avec la clé secrète et la compare à celle du jeton. Seule cette étape garantit que le jeton est authentique et n'a pas été falsifié. Elle doit toujours s'effectuer côté serveur, là où la clé reste protégée.

Ne vous fiez donc jamais aux revendications d'un jeton décodé pour autoriser une action sans avoir d'abord vérifié sa signature. Un attaquant pourrait fabriquer un jeton avec n'importe quelles données. Pour examiner la structure JSON obtenue plus en profondeur, le formateur JSON présente la charge utile de façon claire et indentée.

Déboguer l'authentification au quotidien

Le décodeur JWT devient un allié précieux dès qu'un problème d'authentification surgit. Plutôt que de deviner, vous inspectez directement le jeton en cause pour identifier la source du dysfonctionnement.

Le scénario le plus fréquent est le jeton expiré. En lisant la revendication exp, vous confirmez immédiatement si la durée de validité est dépassée, ce qui explique un refus d'accès soudain. Le décodeur signale cet état pour éviter toute ambiguïté.

Un autre cas classique concerne les permissions manquantes. Si un utilisateur n'accède pas à une ressource, l'examen des revendications de rôle révèle souvent qu'un champ attendu est absent ou mal renseigné.

Le jeton se manipule par parties encodées en Base64URL. Pour comprendre cet encodage sous-jacent, l'encodeur Base64 et le décodeur Base64 éclairent le mécanisme. Garder cet outil à portée de main transforme un débogage long et frustrant en une vérification de quelques secondes, lisible et sans ambiguïté.

Celles que nous répondons le plus souvent.

Le décodeur vérifie-t-il la signature du jeton ?

Non, cet outil décode le contenu sans valider la signature. Le décodage transforme simplement les parties Base64URL en JSON lisible, ce qui ne requiert aucune clé. La vérification de la signature, qui prouve l'authenticité du jeton, doit toujours s'effectuer côté serveur avec la clé secrète. Ne vous fiez jamais à un jeton décodé pour autoriser une action sensible.

Mon jeton est-il transmis à un serveur lors du décodage ?

Le décodage s'effectue directement dans votre navigateur, donc le jeton ne quitte pas votre appareil. Vous pouvez ainsi inspecter un jeton sensible sans risque de transmission externe. Restez néanmoins prudent : un JWT actif reste un identifiant valide, évitez de le partager ou de le coller dans des outils en lesquels vous n'avez pas confiance.

Pourquoi puis-je lire le contenu sans aucune clé ?

Parce qu'un JWT standard n'est pas chiffré, seulement signé. L'en-tête et la charge utile sont encodés en Base64URL, un encodage public et réversible, pas un chiffrement. La signature protège l'intégrité du contenu, pas sa confidentialité. C'est pourquoi il ne faut jamais placer d'informations secrètes dans la charge utile d'un jeton.

Comment savoir si un jeton est expiré ?

Regardez la revendication exp, exprimée en secondes depuis le 1 janvier 1970. Le décodeur la convertit en date lisible et indique si l'échéance est dépassée. Un jeton expiré est normalement rejeté par le serveur, ce qui explique de nombreux refus d'accès soudains lors du débogage d'une authentification.

Que signifient les revendications iss, sub et aud ?

Ce sont des revendications standardisées. iss désigne l'émetteur du jeton, sub identifie le sujet, généralement l'utilisateur concerné, et aud précise le destinataire prévu. Ces champs aident le serveur à vérifier qu'un jeton provient de la bonne source et qu'il est bien destiné à l'application qui le reçoit.

Puis-je modifier un jeton avec cet outil ?

Le décodeur sert à inspecter, pas à forger un jeton valide. Vous pouvez lire les valeurs, mais modifier la charge utile invaliderait la signature, qui ne correspondrait plus au contenu. Un serveur correctement configuré rejetterait alors le jeton. Recréer une signature valide exige la clé secrète, qui reste protégée côté serveur.