Décodeur JWT

Comprendre les revendications à l'intérieur

Une fois un token décodé, la charge utile est surtout une poignée de champs courts et standardisés appelés revendications (claims). Ceux que vous rencontrerez constamment : iss nomme l'émetteur qui a créé le token, sub identifie l'utilisateur ou le sujet concerné, aud nomme l'audience — l'API à laquelle il est destiné — tandis qu'iat enregistre le moment de l'émission et exp celui où il cesse d'être valide. Tout le reste est personnalisé : rôles, adresses e-mail, indicateurs de fonctionnalités, tout ce que le système émetteur a décidé d'y intégrer. Les revendications temporelles piègent les gens parce que ce sont de simples timestamps Unix, des secondes depuis 1970 — un nombre comme 1784528768 plutôt qu'une date lisible — si bien que toute la durée de vie du token se cache dans deux entiers d'apparence anodine.

Déboguer un token rejeté

Quand une API répond 401 et que vous êtes sûr que le token est correct, parcourez une courte liste. D'abord, si vous l'avez copié depuis un en-tête Authorization, retirez le mot Bearer et l'espace devant — avec ceux-ci attachés, ce n'est même plus un JWT valide et il ne se décodera pas du tout. Ensuite, lisez exp et vérifiez qu'elle est bien dans le futur : collez le nombre dans le convertisseur de timestamp Unix et vous verrez l'expiration sous forme de vraie date, révélant souvent un token mort depuis des heures. Comparez ensuite aud et iss avec l'API que vous appelez — un token créé pour l'environnement de test est régulièrement, et à juste titre, refusé par la production. Et souvenez-vous qu'une minute de décalage d'horloge entre serveurs suffit à faire paraître un token tout juste émis comme pas encore valide.

Les tokens que cet outil ne peut pas ouvrir

Tout ce qui protège une API n'est pas un JWT lisible. Un token à cinq parties séparées par des points au lieu de trois est un JWE — réellement chiffré, pas simplement encodé — et rien de lisible n'en ressort sans la clé, ici ou ailleurs. Et beaucoup de tokens de session sont simplement des chaînes aléatoires opaques qui n'ont jamais été des JWT au départ ; s'il ne commence pas par quelque chose comme eyJ, il n'y a probablement rien à décoder. Pour les tokens qui s'ouvrent bel et bien, il est utile de se rappeler ce que l'on regarde : trois blocs de texte Base64URL collés ensemble avec des points. L'outil Base64 décode n'importe lequel de ces blocs isolément, ce qui est une bonne façon de constater de ses propres yeux que les parties lisibles d'un JWT n'ont jamais été secrètes.

Ce que le décodage d'un JWT vous apprend — et ce qu'il ne vous apprend pas

L'en-tête et le contenu d'un JWT ne sont que du JSON encodé en Base64URL — n'importe qui peut les décoder et les lire, sans secret requis, ce qui est exactement ce que fait cet outil. Ce qu'il ne peut pas faire, c'est vérifier la signature : cela nécessite la clé secrète ou publique de l'émetteur, une donnée que vous ne devriez délibérément jamais coller dans un site web quelconque.