Ce que révèle le décodage d’un JWT
Un JSON Web Token signé en format compact comprend généralement trois parties séparées par des points : en-tête, contenu et signature. Cet outil décode les deux premiers segments Base64url en objets JSON UTF-8 afin de rendre leurs déclarations lisibles. Il ne vérifie pas le troisième segment. Un décodage réversible ne prouve ni l’identité de l’émetteur, ni l’intégrité du jeton, ni son acceptation par un serveur. L’en-tête peut annoncer un algorithme ; le contenu peut mentionner émetteur, audience, sujet et champs propres à une application. Considérez ces valeurs comme non fiables tant qu’une application n’a pas appliqué sa politique complète de validation. La valeur saisie reste dans le navigateur.
Lire exp, nbf et iat en secondes
Les champs temporels JWT exp, nbf et iat utilisent NumericDate, soit des secondes écoulées depuis l’époque Unix. Le nombre 2 000 000 000 désigne des secondes, non des millisecondes. Le décodeur affiche la date UTC correspondante à côté de la valeur brute pour examiner une expiration, une date de début de validité ou une émission inattendue. La date traduit simplement une déclaration du contenu ; elle ne valide pas le jeton. Collez le jeton d’exemple et comparez exp avec sa date UTC. Un producteur qui insère par erreur un horodatage de treize chiffres en millisecondes obtient une date invraisemblablement lointaine ou inutilisable. Corrigez la source plutôt que de transformer le nombre sans comprendre sa convention. Comparez les journaux en UTC.
Procédure de diagnostic
Prenez un jeton de test provenant d’un environnement de développement maîtrisé. Vérifiez la présence de l’émetteur, de l’audience et du sujet attendus, puis comparez exp et nbf avec l’heure de la requête en échec. Si le contenu paraît correct mais que le serveur refuse le jeton, examinez la vérification de signature, le choix de la clé et les règles de l’application côté serveur. Le décodeur ne sait pas si ce serveur acceptera le jeton. Le contenu est seulement encodé, non chiffré : une personne possédant le jeton peut lire ses noms et données privées. Ne publiez pas de vrais jetons d’accès dans un ticket, une capture, une adresse URL ou un exemple. Copier le résultat local peut aussi le divulguer.
Limites et pièges de confiance
Un JWE chiffré à cinq parties n’est pas le jeton signé à trois parties pris en charge ici. Les segments Base64url incorrects, l’UTF-8 invalide et un en-tête JSON qui n’est pas un objet sont rejetés plutôt que corrigés discrètement. L’outil ne récupère pas de clés, ne vérifie pas la signature JWS, ne contrôle pas la liste d’algorithmes admis, l’audience attendue ou les tolérances d’horloge. Ces décisions relèvent d’une bibliothèque de validation bien configurée. Un champ admin décodé ne donne aucun droit par lui-même : un jeton altéré peut afficher ce rôle avec une signature invalide. Une date exp future ne suffit pas non plus ; émetteur, révocation ou politique locale peuvent entraîner un refus.