Skip to main content
Aller au contenu principal
Développement28 juillet 2026 8 min de lecture

Décoder un JWT depuis les journaux

Une requête en échec laisse généralement le jeton dans une ligne de journal. Décodez-le localement pour voir exp, iat, iss et aud avant de toucher au code – et ne le collez jamais dans un décodeur quelconque.

Décodez les JWT localement avec le décodeur JWT. Collez le jeton, lisez les claims, et rien n'est envoyé.

Pourquoi les jetons finissent dans les journaux d'erreur

La trace de pile dit 401, les en-têtes de requête ont été journalisés pour le débogage, et le voilà : un JWT complet dans la sortie du journal, souvent d'une exécution de test ou d'un client mal configuré.

Ce jeton n'est pas que du bruit. Il contient des claims – sujet, émetteur, audience, expiration – qui vous disent exactement pourquoi l'authentification a échoué, à condition de savoir les lire.

Le problème est la façon de les lire. Coller un jeton dans un décodeur en ligne quelconque l'envoie au serveur de ce site, où il peut être journalisé, stocké ou rejoué. Un JWT est un identifiant de type bearer dans de nombreuses configurations ; traitez-le comme sensible.

Ce que contient un JWT

Un JWT a trois parties séparées par des points : en-tête, payload et signature. L'en-tête et le payload sont du JSON encodé en Base64URL, lisible par n'importe qui – l'encodage n'est pas du chiffrement.

La signature est la seule partie qui exige la clé de signature pour être produite, mais vous n'en avez pas besoin pour déboguer les claims. Décoder signifie simplement lire les deux premiers segments.

Claims courants à vérifier : exp (expiration, secondes Unix), iat (émis à), nbf (pas avant), iss (émetteur), aud (audience), sub (sujet) et tous les claims personnalisés ajoutés par votre service.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Déboguer un jeton depuis une ligne de journal

  1. Copiez le JWT complet depuis le journal – incluez les deux points, sinon le décodage échouera.
  2. Ouvrez le décodeur JWT dans votre navigateur.
  3. Collez le jeton. Le décodeur affiche les claims d'en-tête et de payload sans rien envoyer à un serveur.
  4. Vérifiez exp par rapport à l'heure Unix actuelle, puis vérifiez iat et nbf : un jeton rejeté comme expiré cinq minutes après son émission est généralement un problème de dérive d'horloge ou de fuseau.
  5. Comparez iss et aud avec ce que votre API attend – les incompatibilités produisent exactement le genre de 401 qui laissent des jetons dans les journaux.
  6. Masquez le jeton avant de partager des journaux avec qui que ce soit, même en interne.

Décoder n'est pas vérifier

Décoder vous permet de lire les claims ; vérifier prouve que le jeton a été signé par la clé attendue et n'a pas été modifié.

Pour le débogage, décoder suffit généralement à identifier l'échec. Pour tout ce qui accorde un accès, vérifiez toujours la signature avec la clé publique de l'émetteur et validez exp, nbf, iss et aud.

Si un site décodeur prétend vérifier les signatures, méfiez-vous : la vérification exige la clé secrète, qu'un service distant ne devrait jamais vous demander de coller.

Avertissement: Ne collez jamais un jeton dans un site qui demande le secret de signature, et ne collez jamais de jetons de systèmes de production dans des outils en ligne non vérifiés. Le décodage local côté client est la valeur sûre.

Ce que les claims révèlent généralement

SymptômeClaim à vérifierCorrectif typique
401 immédiatement après l'émissioniat / nbf / horloge serveurCorrigez la dérive d'horloge, permettez une tolérance, synchronisez l'heure du serveur
Le jeton fonctionnait, puis a cesséexpRenouvelez ou ré-authentifiez ; vérifiez le réglage d'expiration
Rejeté par l'API mais se décode bieniss / audAlignez la configuration d'émetteur et d'audience
Erreurs de signature invalideen-tête alg + incompatibilité de cléVérifiez la clé de signature et l'algorithme des deux côtés

Empêcher les jetons d'atteindre les journaux

  • Ne journalisez jamais les en-têtes Authorization ni les valeurs de cookies en production
  • Masquez ou tronquez les jetons dans la sortie de débogage
  • Utilisez des journaux structurés pour pouvoir filtrer les champs sensibles centralement
  • Ajoutez un contrôle CI qui échoue quand un motif de type JWT apparaît dans la sortie de test
  • Faites tourner les jetons journalisés ou partagés en clair

FAQ

Q.Est-il sûr de décoder un JWT en ligne ?

A.Uniquement si l'outil est côté client et ne fait aucune requête réseau avec votre jeton. Sur ce site, le décodage se déroule localement dans votre navigateur. Tout outil qui téléverse le jeton doit être évité pour les identifiants de production.

Q.Pourquoi mon jeton indique-t-il expiré alors que je viens de le créer ?

A.Vérifiez l'horloge et le fuseau du serveur. exp est en secondes Unix – si l'horloge du serveur est en avance, ou si vous avez généré le jeton avec une source de temps différente, un jeton peut sembler expiré immédiatement. La tolérance de dérive d'horloge corrige généralement cela.

Q.Ai-je besoin du secret pour décoder un JWT ?

A.Non. L'en-tête et le payload sont du JSON encodé en Base64URL brut. Vous n'avez besoin du secret que pour vérifier la signature, et vous ne devriez jamais le partager avec un outil distant.

Q.Pourquoi l'en-tête indique-t-il alg : none ?

A.Un algorithme none signifie que le jeton n'est pas signé – un attaquant peut forger n'importe quels claims. Les serveurs doivent rejeter none entièrement. Si vous le voyez dans vos journaux, vérifiez immédiatement la configuration de votre bibliothèque de jetons.

Q.Quelqu'un peut-il utiliser un jeton trouvé dans un journal ?

A.Jusqu'à son expiration, oui, s'il est accepté comme identifiant bearer et que l'audience correspond. Traitez les jetons journalisés comme compromis, masquez les journaux et faites tourner le jeton.

Références

  • RFC 7519 – JSON Web Token (JWT) : https://www.rfc-editor.org/rfc/rfc7519
  • RFC 7515 – JSON Web Signature (JWS) : https://www.rfc-editor.org/rfc/rfc7515
  • RFC 4648 – Encodages Base64 et Base64URL : https://www.rfc-editor.org/rfc/rfc4648
  • Aide-mémoire OWASP JWT : https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html

Décodez les JWT localement

Claims d'en-tête et de payload dans votre navigateur. Rien n'est jamais envoyé.

Lisez le jeton, gardez le jeton privé

Les claims d'un JWT journalisé expliquent généralement l'échec plus vite que la lecture du code. Décodez localement, vérifiez les quatre claims standard et corrigez la cause racine plutôt que le symptôme.

Utilisez le décodeur JWT – côté client, sans envoi, sûr pour les jetons de production.

décoder jwtjournal d'erreur jwtdécoder jeton jwtdébogage jwtdécoder payload jwtjwt depuis les journauxjwt sans vérificationclaims jwt