Décodeur JWT

Ce que fait réellement un décodeur JWT

Un jeton web JSON (JWT) ressemble à une longue chaîne opaque de caractères aléatoires, mais il n'est ni chiffré ni protégé par un cryptage secret. C'est un conteneur compact et compatible URL qui transporte des données structurées entre deux parties. Collez un jeton dans le décodeur ci-dessus : il sépare cette chaîne et vous montre le véritable JSON à l'intérieur — les métadonnées, les revendications, à qui le jeton est destiné, et quand il expire. Tout se passe directement dans votre navigateur. Le jeton n'est jamais envoyé, journalisé ni transmis où que ce soit, ce qui compte énormément lorsque l'objet que vous inspectez est un identifiant de session actif.

Trois parties, deux points

Tout JWT bien formé se compose de trois chaînes encodées en Base64url reliées par des points : en-tête.charge_utile.signature. Ce simple caractère point indique aux analyseurs où finit une section et où commence la suivante, et c'est pourquoi un jeton avec un nombre de points incorrect est rejeté avant même que quoi que ce soit d'autre ne soit lu.

L'en-tête est un minuscule objet JSON décrivant le jeton lui-même. Il contient presque toujours typ (le type, généralement JWT) et alg — l'algorithme de signature, tel que HS256 (HMAC avec SHA-256) ou RS256 (RSA avec SHA-256). L'en-tête indique à un vérificateur exactement comment la signature a été produite.

La charge utile est la partie qui intéresse la plupart des gens. C'est un autre objet JSON contenant les revendications — des affirmations sur l'utilisateur et le jeton. La spécification classe les revendications en enregistrées (noms standard et réservés), publiques, et privées (noms personnalisés que vous inventez pour votre propre application). Décoder la charge utile révèle qui est connecté, quel rôle il détient, et quand sa session expire.

La signature est le sceau cryptographique. Elle est calculée sur l'en-tête et la charge utile encodés à l'aide de l'algorithme de l'en-tête plus une clé secrète ou privée. Comme elle couvre les deux autres sections, toute modification de l'en-tête ou de la charge utile — ne serait-ce qu'un seul caractère — l'invalide.

Les revendications que vous verrez le plus souvent

Les revendications enregistrées sont des noms courts de trois lettres définis par la RFC 7519 afin que différents systèmes puissent interopérer. Une poignée apparaît presque partout :

• iss — issuer (émetteur) : qui a généré le jeton (votre serveur d'authentification ou fournisseur d'identité).
• sub — subject (sujet) : l'entité que concerne le jeton, généralement un identifiant utilisateur stable.
• aud — audience : le destinataire auquel le jeton est destiné. Une API doit rejeter les jetons dont l'audience n'est pas elle-même.
• exp — expiration time (date d'expiration) : un horodatage Unix après lequel le jeton ne doit plus être accepté.
• iat — issued at (émis le) : l'horodatage Unix de création du jeton.

Vous pourrez aussi rencontrer nbf (not before, pas avant) et jti (un identifiant unique de jeton). Les horodatages sont des secondes depuis 1970 en UTC, raison pour laquelle un décodeur qui les affiche sous forme de dates lisibles vous épargne le calcul mental pour vérifier si un jeton a déjà expiré.

Décoder n'est pas vérifier — c'est là que ça coince

Cette distinction est la chose la plus importante à comprendre au sujet des JWT. Décoder signifie lire le contenu : cela ne requiert aucune clé et quiconque détient le jeton peut le faire, car le Base64url est un encodage, pas du chiffrement. Vérifier signifie prouver que le jeton est authentique et non altéré — recalculer la signature avec la bonne clé secrète ou publique et confirmer qu'elle correspond.

Cet outil décode. Il vous montre ce que le jeton dit, pas si le jeton est digne de confiance. Un jeton pourrait être falsifié, expiré ou rejoué et néanmoins se décoder en un JSON parfaitement propre en apparence. Ne prenez jamais une décision d'autorisation sur la seule base des revendications décodées. En production, vous vérifiez la signature côté serveur, vous contrôlez exp, et vous confirmez que iss et aud correspondent à ce que vous attendez — à l'aide d'une bibliothèque éprouvée, jamais d'une comparaison de chaînes faite maison.

Une charge utile n'est pas un coffre-fort

Comme la charge utile est seulement encodée en Base64url, elle est lisible par quiconque intercepte le jeton. Considérez tout ce qu'elle contient comme public. Ne placez pas de mots de passe, de numéros de carte de crédit complets, de clés secrètes ou de données personnelles sensibles dans les revendications d'un JWT — si vous pouvez le décoder ici en un clic, n'importe qui d'autre en possession d'une copie le peut aussi. La signature protège contre la modification, jamais contre la lecture. Si vous devez vraiment masquer le contenu de la charge utile, c'est le rôle de JWE (jetons chiffrés), une spécification entièrement différente.

Confidentialité et outils connexes

Inspecter un jeton est un acte sensible, ce décodeur s'exécute donc entièrement côté client — l'analyse est du simple JavaScript dans votre onglet et rien ne quitte votre machine. Coller un jeton de session dans un outil hébergé sur serveur revient à confier un identifiant actif à un tiers, ce qui est exactement ce que vous devez éviter. Pour l'encodage qui sous-tend tout cela, consultez notre outil Base64, et explorez le reste de nos outils pour développeurs pour davantage d'utilitaires fonctionnant sur l'appareil.

Questions fréquentes