Décodeur JWT et inspecteur de claims

Décode un JWT, lis ses claims et pèse le risque lié à la signature, le tout dans ton navigateur.

Ce décodeur JWT ouvre un token direct dans ton navigateur et montre ce qu'il raconte vraiment. Colle un JWT pour lire le header et le payload, transformer les affreux timestamps Unix de exp, nbf et iat en dates qu'un humain peut lire, et comparer l'issuer et l'audience à ce que tu attendais. Il signale les tokens expirés et ceux pas encore valides, gueule dès qu'il voit alg none, et liste les alertes à regarder à deux fois avant qu'un token s'approche de ton code. Charge les exemples access, expiré ou alg none pour voir chaque cas, puis copie le JSON décodé ou un rapport de sécurité. Voilà le truc honnête : il décode le token, il ne le vérifie pas. La signature, c'est toujours à toi de la contrôler contre le bon secret ou la bonne clé publique. Rien de ce que tu colles ne quitte jamais la page.

100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.

Décodeur JWT local, inspecteur de claims et checklist de vérification

Colle un JWT. Je te l'ouvre direct, ici, dans ton navigateur. Tu récupères le header et le payload, les dates d'expiration et de not-before écrites en clair, plus un petit verdict sur le fait que l'issuer et l'audience correspondent bien à ce que tu attendais. Sauf qu'il y a un truc honnête à préciser. Je décode le token. Je ne le vérifie pas. La signature, c'est toujours à toi de la contrôler avant de faire confiance à la moindre claim, et je t'expliquerai plus bas pourquoi cet écart change tout.

Entrée JWT

Issuer attendu

Audience attendue

Décalage d'horloge (minutes)

Tout tourne dans ton navigateur, donc le token ne quitte jamais cette page. Et pour être franc : je ne teste pas la signature contre un secret, une clé publique ou un endpoint JWKS. Tu lis ce que le token raconte sur lui-même. Ce n'est pas la même chose qu'une preuve qu'il dit vrai.

Un décodeur JWT n'est que la première étape

Ce décodeur JWT découpe un token en sections Base64URL dans ton navigateur, et ça, c'est la partie facile. Faire confiance à ce qu'il y a dedans ? Tout autre histoire, et c'est là que les gens se brûlent. Le header te dit quel algorithme et quelle clé étaient censés être utilisés. Le payload trimballe l'identité, l'issuer et l'audience, l'expiration, les scopes et les rôles, plus toutes les claims maison que quelqu'un a bricolées à 2h du mat. Rien de tout ça ne garantit l'intégrité, pourtant. La signature ne commence à vouloir dire quelque chose qu'une fois que ton appli la vérifie pour de vrai avec la bonne clé et claque la porte au nez des algorithmes dangereux.

Je l'ai construit pour le débogage que je finis par faire en boucle. Il décode le header et le payload, lit les registered claims, et transforme ces affreux timestamps Unix en dates qu'un humain peut vraiment lire. Il vérifie l'issuer et l'audience contre ce que tu lui as dit d'attendre. Il signale les tokens expirés et ceux pas encore valides. Il gueule dès qu'il voit alg: none. Et il n'arrête pas de te rappeler qu'une signature que tu peux voir n'est pas une signature que quelqu'un a vérifiée. Je le dégaine devant des logs d'API, en démêlant un handshake OAuth, en bidouillant OpenID Connect sur ma propre machine, ou en chassant un ticket de support où j'ai juste besoin de savoir ce que le token raconte vraiment.

Comment lire un JWT sans se faire avoir

Commence par la forme. Un JWT signé normal, ce sont trois sections séparées par des points : header, payload, signature. Décode les deux premières en Base64URL et hop, du JSON ressort. Maintenant les claims de temps. exp, c'est le moment où le token devrait cesser d'être accepté. nbf, c'est quand il devient valide. iat, c'est quand il a été émis. Ensuite, compare iss et aud au service exact que tu attendais, pas à un service qui s'en rapproche à peu près. Voilà le détail que les gens zappent. Un token qui se décode proprement mais qui a été émis pour une autre API, ce n'est pas ton token. Ne le laisse pas passer juste parce que le JSON est ressorti tout propre.

Header te dit l'algorithme et le type de token, plus des indices pour la sélection de clé comme kid.
Payload, c'est là que vivent les registered claims, à côté de tout ce que ton appli y a ajouté.
Timeline des claims, c'est comme ça que tu attrapes les tokens expirés. Et ceux datés dans le futur. Et les quelques-uns qui sont juste bizarrement vieux.
Signature doit être vérifiée côté serveur, ou contre une clé publique de confiance, avant que tu t'appuies dessus.
Alertes, c'est ma petite liste des trucs à regarder à deux fois avant qu'un token s'approche du code.

Situations courantes de débogage de JWT

Une API te renvoie un 401 ? Décode le token d'abord. Jette un œil à l'audience, à l'issuer, à l'expiration et au scope avant de te lancer à réécrire du code backend. J'ai cramé des heures sur un « bug » qui s'est avéré être un seul token expiré, et je parie que je ne suis pas le seul. Coincé dans une boucle de login en frontend ? Regarde si le navigateur a reçu un truc déjà expiré, ou un truc avec nbf placé dans le futur parce que deux horloges sont décalées de quelques minutes. Si le token porte un kid, suis la metadata de l'issuer ou une URL JWKS de confiance jusqu'à la clé publique correspondante. Et la règle que je ne plierais jamais : n'accepte pas un token juste parce que le payload a l'air correct. N'importe qui peut taper un payload crédible. C'est la signature qui est dure à forger. C'est un peu tout l'intérêt du truc, en fait.

Questions fréquentes

Est-ce que ça vérifie mon JWT ?

Non, et je ne vais pas faire semblant du contraire. Ça décode le token et l'inspecte, ici même, dans ton navigateur. La vraie vérification, elle exige le bon secret ou la bonne clé publique, une allowlist stricte d'algorithmes, et de vraies vérifs d'issuer et d'audience. Ce boulot, sa place est dans ton code. Pas sur une page web.

Est-ce qu’un JWT est chiffré ?

Nope. Un JWT classique est signé, pas chiffré. N'importe qui qui le tient lit le header et le payload en quelques secondes. Donc tout ce que tu balances dedans, pars du principe que le monde entier peut le voir. Range tes secrets ailleurs.

Est-ce que décoder un JWT le vérifie ?

Non. Décoder, ça ne fait que retransformer le header et le payload en JSON. Vérifier, ça veut dire contrôler la signature contre le secret ou la clé publique, et un simple décodeur ne touche jamais à cette étape. C'est facile à confondre. Et aussi pénible à se rater en production.

Est-ce que c’est safe de mettre des données sensibles dans un JWT ?

Non. Le payload est lisible par absolument n'importe qui, parce qu'il est signé et pas chiffré. Donc ne planque jamais de secrets dans un JWT. N'y mets que ce que tu serais OK de voir fuiter, parce qu'honnêtement, c'est déjà le cas dans les faits.