JWT encode/decode : fabriquer et inspecter un token en ligne

Le décodeur et l'encodeur couvrent tout ce qui n'exige pas d'établir la confiance envers un émetteur.

Faire confiance à un token demande des clés, des claims et une politique, pas seulement un payload lisible. Passez la main à jwt-verify, à inspect-jwks ou à votre propre code.

Collez le token dans le décodeur et lisez les claims de temps avant de toucher à l'API. exp, nbf et iat sont des NumericDate : des secondes depuis le 1er janvier 1970 UTC (RFC 7519).

Quand les claims sont bons et que l'API refuse quand même, le problème se trouve dans l'en-tête ou la signature.

Un 403 signifie que le token a été accepté et que l'étape d'autorisation a dit non. Le payload dit généralement pourquoi.

Un décodeur montre ce qu'un token affirme, pas qui l'a écrit. Le payload n'est pas protégé : quiconque a le token, ou peut en fabriquer un, peut y mettre n'importe quel claim. L'encodeur peut même produire un token non sécurisé avec alg=none, dont le segment de signature est vide : les outils l'étiquettent « JWT non signé (alg=none) », et aucun vérificateur ne devrait jamais l'accepter. La RFC 8725 (bonnes pratiques JWT) demande aux serveurs de n'accepter que les algorithmes attendus et de ne jamais laisser le token choisir. La confusion d'algorithme est la défaillance classique : un token qui déclare HS256 et qui est signé avec la clé publique d'un service RS256 passe chez un vérificateur qui lit alg dans l'en-tête et utilise la clé publique comme secret HMAC.

Base64URL est un encodage, pas un chiffrement : le guide Base64 explique la différence. Un JWT signé (JWS) garantit seulement l'intégrité, donc tout le payload est lisible. Il existe des tokens chiffrés (JWE, RFC 7516, cinq parties au lieu de trois), mais le décodeur d'ici ne traite que les tokens signés. Un token est aussi un identifiant d'accès : qui le détient peut l'utiliser jusqu'à exp. Cet outil le garde dans votre onglet, mais un partage d'écran, une capture partagée ou un ticket collé avec le token le divulgue quand même.

HS256 signe avec un secret partagé, et la RFC 7518 demande une clé au moins aussi longue que la sortie du hash : 256 bits pour HS256, 384 pour HS384, 512 pour HS512. Quand votre secret est plus court, l'encodeur affiche sa taille en bits face au minimum recommandé. Ce chiffre est la longueur de la clé, pas son caractère aléatoire : une phrase de 32 caractères en français fait 256 bits de long et reste devinable. Un attaquant qui détient un seul token peut tester des secrets candidats hors ligne contre sa signature, sans jamais toucher votre API. Tirez le secret au hasard, par exemple avec le générateur de mot de passe (voir le guide mot de passe) : environ 41 caractères de son jeu par défaut de 82 caractères portent 256 bits d'entropie. L'option Base64URL change les octets utilisés : cochée, la chaîne du secret est décodée en Base64URL et ses octets forment la clé ; décochée, ce sont les caractères eux-mêmes. Le même texte avec le mauvais réglage donne une autre signature.

L'encodeur est conçu pour les fixtures et le débogage. Il réécrit iat à maintenant, peut supprimer entièrement la signature, et les exemples qu'il charge utilisent des secrets jetables. Un token signé ici avec un secret de démonstration ne doit jamais être accepté par un environnement réel, et un vrai secret de signature ne doit jamais être collé dans un fichier que vous commitez ensuite. Si c'est déjà arrivé, changez-le, et scannez votre diff avant de commiter avec le scanner de secrets.

La forme compacte, ce sont trois segments Base64URL joints par des points. C'est ce qui voyage dans un en-tête Authorization: Bearer.

Sept claims enregistrés (RFC 7519) couvrent la plupart des séances de débogage. Tous sont facultatifs dans la spécification, donc une API peut en exiger plus que la norme.

La valeur d'alg décide qui peut émettre un token et qui peut seulement en contrôler un.

Le décodeur JWT n'a pas de bouton : le décodage s'exécute pendant que vous collez ou modifiez, après une courte pause. L'éditeur démarre vide ; « Charger un exemple » ou le choix d'un algorithme charge un token de démonstration.

L'encodeur JWT signe pendant que vous tapez. Le token apparaît dès que l'en-tête, le payload et la clé sont valides.

Quelques limites à connaître avant de s'appuyer dessus pour un usage précis.

Le décodage n'exige aucune bibliothèque : découpez sur les points et lisez chaque segment en Base64URL. C'est ce que fait le décodeur, avec la même limite : rien n'est contrôlé.

La bibliothèque jose signe un JWT compact et renseigne les claims enregistrés pour vous. Contrairement à l'encodeur d'ici, setIssuedAt() utilise la vraie horloge, comme il se doit en production.

La vérification est l'endroit où se fonde la confiance : imposez l'algorithme, l'émetteur et l'audience, et autorisez une petite tolérance d'horloge.

Rien à installer, rien d'envoyé : le décodeur et l'encodeur couvrent la lecture des claims, la fabrication de fixtures et le contrôle d'une signature dont vous détenez la clé. Les compromis : pas de validation des claims, pas de conversion d'horodatages, pas de JWE, EdDSA limité à Ed25519. Pour une vraie décision de confiance, utilisez une bibliothèque de vérification côté serveur, ou collez un JWKS dans jwt-verify pour tester d'abord votre politique.