Décodez les jetons JWT localement avec notre décodeur JWT. Votre jeton ne quitte jamais votre navigateur.
Pourquoi les JWT apparaissent sans cesse dans le CI
Les tests d'intégration, les suites de bout en bout et les scripts de déploiement ont souvent besoin d'un jeton d'accès. Quand un test échoue, le jeton atterrit dans la sortie du journal, et l'étape naturelle suivante est de regarder à l'intérieur.
Décoder un JWT est sûr : l'en-tête et le payload sont seulement encodés en base64url, pas chiffrés. Le risque n'est pas de décoder – c'est de coller le jeton, ou pire, la clé de signature, dans un outil côté serveur qui peut le journaliser.
La plupart des échecs de jeton dans le CI tiennent à quelques causes. Le jeton a expiré pendant que le job attendait dans la file, l'horloge du runner diffère de celle de l'émetteur, ou le jeton a été créé pour un autre environnement.
Anatomie d'un JWT en 60 secondes
Les trois parties sont séparées par des points, et chacune est encodée en base64url sans rembourrage. C'est pourquoi un JWT ressemble à une chaîne de lettres, de chiffres et de tirets plutôt qu'à du JSON lisible.
| Partie | Ce qu'elle contient | Exemple |
|---|---|---|
| En-tête | Algorithme et type de jeton | "alg": "RS256" |
| Payload | Claims comme sub, exp, iat, iss | "exp": 1780000000 |
| Signature | Résumé avec clé qui vérifie l'intégrité | octets encodés en base64url |
Remarque: Seule la signature exige la clé. L'en-tête et le payload peuvent toujours être décodés sans aucun secret.
Décoder un jeton CI sans exposer les secrets
- Copiez le jeton depuis le journal CI, en excluant les secrets ou lignes d'environnement environnants.
- Ouvrez le décodeur JWT dans votre navigateur.
- Collez le jeton et inspectez l'en-tête : vérifiez les valeurs alg et kid.
- Inspectez le payload : vérifiez exp, iat, iss et sub par rapport à l'environnement débogué.
- Comparez exp avec l'heure actuelle à l'aide du convertisseur d'horodatage si les valeurs semblent ambiguës.
Avertissement: Ne collez jamais la clé de signature, le secret client ou le jeton d'actualisation dans un outil. Décoder le jeton lui-même suffit à déboguer 90 % des échecs d'authentification.
Problèmes JWT courants que vous trouverez dans le CI
- Jeton expiré : exp est dans le passé, souvent parce que le test a duré plus longtemps que la durée de vie du jeton
- Dérive d'horloge : le serveur émetteur et le runner de test ne sont pas d'accord sur l'heure
- Mauvais émetteur : jeton créé pour un environnement différent (staging vs production)
- Confusion d'algorithme : l'en-tête alg a changé ou ne correspond pas au type de clé
- Entrée malformée : espaces supplémentaires ou caractères encodés URL cassent l'analyse base64url
- Audience incohérente : aud ne correspond pas à ce que l'API attend, la requête est rejetée malgré une signature valide
- nbf dans le futur : le jeton n'est pas encore utilisable car le début de validité n'est pas atteint
FAQ
Q.Décoder un JWT est-il sûr ?
A.Oui. L'en-tête et le payload d'un JWT sont encodés en base64url, pas chiffrés, donc les décoder révèle seulement ce qui était déjà dans le jeton. Quiconque possède le jeton peut le décoder, c'est voulu. Les vrais dangers sont de partager le jeton ou de le laisser dans un journal public.
Q.Un décodeur peut-il vérifier la signature JWT ?
A.Non — un décodeur n'a pas de clé, et la vérification de signature exige la clé de signature ou la clé publique correspondante. Ce que peut faire un décodeur, c'est analyser l'en-tête et le payload pour vérifier alg, kid et les claims. Pour une vraie vérification, utilisez le point de terminaison de validation de votre fournisseur d'identité ou une bibliothèque JWT configurée avec la clé publique.
Q.Que ne dois-je jamais coller dans un outil de débogage ?
A.Ne collez jamais de clés privées, de secrets clients, de jetons d'actualisation ou de jetons pouvant accéder aux données de production. Masquez les données sensibles du payload avant de coller, et préférez un décodeur côté client dont l'entrée ne quitte jamais votre machine.
Q.Pourquoi exp apparaît-il comme un simple nombre ?
A.Parce que exp est une date numérique : des secondes depuis le 1er janvier 1970 UTC. Une valeur comme « 1780000000 » ne dit rien au premier coup d'œil, c'est pourquoi le décodeur JWT l'affiche aussi comme une date lisible. Pour la comparer à l'heure actuelle, utilisez le convertisseur d'horodatage.
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 8725 – Bonnes pratiques actuelles pour les JSON Web Tokens : https://www.rfc-editor.org/rfc/rfc8725
- OWASP – Aide-mémoire JSON Web Token : https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html
Décodez un jeton CI
En-tête et payload dans votre navigateur, en lecture seule, zéro envoi.
Lisez le jeton avant d'accuser le test
Inspectez alg, exp et iss avec le décodeur JWT, convertissez les horodatages avec le convertisseur d'horodatage et comparez avec l'environnement dans lequel le test s'exécute.
Gardez les clés de signature et les jetons de production hors des journaux et des outils de collage.
Quand j'ai dû déboguer un échec de jeton récurrent dans un pipeline nocturne, décoder le jeton a été l'étape qui a mis fin aux suppositions. Le payload montrait un exp déjà dépassé au moment où la file a pris le job : le jeton avait été créé à la compilation, pas à l'exécution, et il était donc déjà périmé.