Décodeur JWT

Un JSON Web Token est trois segments encodés en Base64URL joints par des points : un en-tête décrivant l'algorithme de signature et le type de token, un payload contenant les claims réels — qui le token identifie, quand il expire, quelles permissions il accorde — et une signature calculée sur les deux premiers segments avec un secret ou une clé privée. Décoder, ce que fait cet outil, signifie décoder en Base64URL les deux premiers segments vers du JSON lisible ; cela ne dit rien sur le troisième segment au-delà d'exposer sa valeur encodée brute, car vérifier cette signature nécessite le vrai secret de signature, qu'un outil basé navigateur ne devrait jamais vous demander de coller.

Cette distinction — décoder contre vérifier — est la chose la plus importante à comprendre à propos d'un outil de débogage JWT. Décoder vous dit ce qu'un token *affirme* ; vérifier vous dit si ces affirmations peuvent être *fiables*, en confirmant que la signature a été produite par l'émetteur attendu. Un token peut se décoder parfaitement et afficher un payload prétendant un accès administrateur tout en étant complètement falsifié, si rien ne vérifie jamais la signature contre la vraie clé de signature.

L'en-tête et le payload sont encodés, pas chiffrés — Base64URL est une transformation réversible sans aucun secret impliqué, donc quiconque obtient un token, que ce soit en interceptant du trafic réseau, en lisant le stockage du navigateur, ou en le recevant directement, peut décoder le payload et lire chaque claim dedans sans avoir besoin d'aucune clé. C'est précisément pourquoi le conseil standard est de garder les payloads JWT limités à des identifiants et claims non sensibles — un ID utilisateur, un rôle, une durée d'expiration — et de ne jamais placer un mot de passe, un numéro de carte de crédit, ou une autre donnée confidentielle directement dans le token, le format du token n'offrant aucune confidentialité par lui-même.

Les claims d'horodatage standard sont stockés en temps Unix — un simple entier comptant les secondes depuis le 1er janvier 1970 — ce qui est efficace pour que des machines comparent mais illisible d'un coup d'œil pour une personne déboguant un token à vue. Convertir `1735689600` en « 1er janvier 2025, 00:00:00 UTC » à la main est exactement le genre de petit calcul propice aux erreurs, facile à rater sous pression temporelle, en particulier entre fuseaux horaires. Rendre les trois claims comme de vraies dates locales, et déclarer directement si le token est actuellement expiré, valide, ou pas encore actif, transforme une session de débogage qui impliquerait sinon un calcul secondaire en une réponse immédiate et lisible.