Lire un JWT de test sans le confondre avec un jeton valide

Le décodeur JWT rend lisibles un en-tête et un contenu JSON. Il ne confirme pas que le jeton a été émis par le bon service, qu’il est encore utilisable ou que sa signature est correcte. Pour apprendre ou préparer un ticket, commencez par des données fictives.

Préparer un exemple sans secret

N’utilisez pas un jeton de production pour reproduire ce tutoriel. Un jeton d’accès porteur peut donner accès à ses ressources à la personne qui le détient ; la RFC 6750 décrit ce risque. Même expiré, un jeton peut encore révéler des données dans son contenu.

Copiez cette chaîne de démonstration. Son troisième segment est volontairement factice : elle ne doit servir à aucune authentification.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLTAwMSIsImF1ZCI6ImRlbW8ifQ.ZmFrZQ

Décoder puis lire le résultat

1. Ouvrez le décodeur de jeton JWT.
2. Collez la chaîne seule dans « JWT en trois parties (en-tête.contenu.signature) », sans préfixe Bearer ni guillemets.
3. Cliquez sur « Décoder le jeton ».
4. Dans header, retrouvez alg : HS256 et typ : JWT. Ces valeurs décrivent ce que le jeton annonce ; elles ne prouvent rien sur sa validité.
5. Dans payload, retrouvez sub : demo-001 et aud : demo. Dans signature, l’outil indique que la signature n’est pas vérifiée.

Ce test est volontairement trompeur du point de vue de l’authentification : le contenu s’affiche correctement malgré une fausse signature. Un résultat lisible signifie ici que l’en-tête et le contenu ont pu être décodés et analysés comme JSON.

Comprendre les champs sans leur faire confiance

La RFC 7519 définit notamment iss pour l’émetteur, sub pour le sujet, aud pour l’audience et exp pour l’expiration. Lorsqu’il existe, exp est une valeur temporelle en secondes depuis l’époque Unix. Tous les exemples n’incluent pas tous les champs ; notre démonstration n’a pas de date d’expiration.

Le convertisseur d’horodatage Unix peut aider à lire une valeur temporelle de test. Cela ne réalise aucune validation du jeton. Le formateur et inspecteur JSON peut servir à examiner une copie fictive du contenu seul.

Un jeton compact chiffré en cinq parties relève du format JWE décrit par la RFC 7516. Ce décodeur ne le déchiffre pas.

Ce qu’il reste à vérifier dans l’application

La lecture ne remplace pas les règles de l’application destinataire : algorithmes autorisés, signature, émetteur, audience et contraintes temporelles pertinentes. Ces contrôles nécessitent notamment les clés et le contexte de confiance appropriés. Les bonnes pratiques de la RFC 8725 expliquent pourquoi il ne faut pas faire confiance aux revendications reçues avant validation.

Pour transmettre un diagnostic à un collègue, décrivez l’erreur et préparez un exemple fictif. Ne joignez pas automatiquement le jeton réel ou une capture de son contenu. Le traitement local évite une requête de décodage vers un serveur, mais ne protège pas une copie ultérieure dans un ticket, un message ou un presse-papiers partagé.

Questions fréquentes

Le contenu d’un JWT signé est-il secret ?

Pas nécessairement. L’encodage rend le contenu transportable, pas confidentiel. La signature et le chiffrement remplissent des fonctions différentes.

Pourquoi un jeton à cinq parties est-il refusé ?

L’outil signale les jetons compacts à cinq parties comme des JWE chiffrés. Il ne réalise pas leur déchiffrement et ne demande pas la clé correspondante.

Pourquoi mon exemple avec une fausse signature fonctionne-t-il ?

L’outil décode seulement l’en-tête et le contenu. Il ne contrôle pas la signature : cet affichage ne doit jamais servir à autoriser un accès.