Décodeur JWT

Comment décoder un JWT

1. Collez le jeton dans Jeton JWT. Une valeur Authorization: Bearer … complète fonctionne aussi : le préfixe Bearer et les retours à la ligne sont supprimés.
2. Le jeton est décodé pendant la saisie (ou avec Décoder). L’En-tête et la Charge utile (payload) s’affichent en JSON indenté, chacun avec son bouton Copier.
3. Consultez le tableau Dates du jeton : exp, nbf et iat y figurent avec leur valeur brute, la date dans votre fuseau horaire, un délai relatif (« dans 3 heures », « il y a 2 jours ») et un état comme Expiré ou Pas encore valide.
4. Lisez les avertissements au-dessus des résultats, par exemple si alg vaut none ou si une date semble exprimée en millisecondes.
5. Pour contrôler la signature, renseignez la clé sous Vérifier la signature, puis cliquez sur Vérifier la signature.

Décoder n’est pas vérifier

Un JWT se compose de trois parties en Base64url séparées par des points : en-tête.charge.signature. L’en-tête et la charge utile sont seulement encodés, pas chiffrés : quiconque possède le jeton peut les lire, et cet outil décode n’importe quel jeton sans clé. Du coup, une charge utile décodée ne prouve rien, elle a pu être modifiée. Seule une signature valide montre que le jeton a été émis par le détenteur de la clé et qu’il n’a pas été altéré. C’est pourquoi la ligne d’état indique « Décodé (signature non vérifiée) » tant que vous n’avez pas vérifié.

Un jeton en cinq parties est un JWE (JWT chiffré) : son contenu reste illisible sans la clé de déchiffrement, et l’outil vous le signale.

Vérifier la signature

• HS256, HS384, HS512 (HMAC) : saisissez le Secret partagé. Le Format du secret précise s’il s’agit de texte (UTF-8) ou de Base64/Base64url, car certains fournisseurs stockent leurs secrets en Base64. Une JWK de type oct est aussi acceptée. Si le secret est plus court que l’empreinte (32 octets pour HS256), l’outil signale qu’il est sous le minimum de la RFC 7518.
• RS256/384/512, PS256/384/512, ES256/384/512 et EdDSA : collez la Clé publique (PEM ou JWK). Les blocs PEM acceptés sont PUBLIC KEY, RSA PUBLIC KEY et CERTIFICATE (la clé est extraite du certificat X.509). Une JWK ou un JWK Set entier convient aussi : la clé dont le kid correspond à l’en-tête est retenue. Les clés privées sont refusées : un vérificateur n’en a jamais besoin. EdDSA prend en charge Ed25519 dans les navigateurs dont Web Crypto l’implémente.

La vérification passe par l’API Web Crypto du navigateur. « Signature invalide » signifie que la clé est mauvaise ou que le jeton a été modifié. Notez que l’algorithme est lu dans l’en-tête du jeton ; un vrai serveur doit au contraire imposer l’algorithme attendu dans sa configuration, sinon un attaquant peut le choisir.

Points de sécurité

• Un jeton est un identifiant. Toute personne qui détient un jeton d’accès valide peut en général agir au nom de son titulaire jusqu’à son expiration. Cet outil décode et vérifie tout dans votre navigateur, sans jamais envoyer le jeton ni la clé. Évitez malgré tout de coller des jetons de production dans des outils que vous ne pouvez pas inspecter.
• alg: none signifie que le jeton n’est pas signé : n’importe qui peut en fabriquer un, et un serveur doit le rejeter. L’outil affiche un avertissement et refuse de « vérifier » ce type de jeton.
• Les contrôles de date utilisent l’horloge de votre ordinateur, sans marge de tolérance ; les serveurs acceptent souvent une ou deux minutes de décalage.
• Les dates JWT (NumericDate) sont des secondes écoulées depuis le 1er janvier 1970 UTC. Une valeur à 13 chiffres est probablement en millisecondes, une erreur fréquente.