Décodeur de JWT

À propos de cet outil

Ce décodeur JWT lit la structure d'un JSON Web Token et affiche son en-tête et son contenu (payload) en clair, les revendications standard (émetteur, sujet, expiration…) avec leurs dates, et l'état de validité du token. Il peut aussi vérifier la signature avec votre clé secrète (HS256, HS384, HS512) ou votre clé publique au format PEM ou JWK (RS256, PS256, ES256…). Tout se passe dans votre navigateur : le token n'est jamais transmis.

Comment utiliser cet outil

1. Collez votre JWT complet dans le champ de saisie, ou chargez l'exemple pour voir le fonctionnement.
2. L'en-tête (header) et le contenu (payload) sont décodés et affichés en JSON lisible.
3. Repérez les pastilles : algorithme, type, et état d'expiration (expiré, valide pour encore…).
4. Consultez le tableau des revendications reconnues (iss, sub, aud, exp, nbf, iat, jti) avec les dates converties.
5. Pour vérifier l'authenticité, saisissez la clé secrète ou la clé publique : l'outil indique si la signature est valide.

Anatomie d'un JWT : trois parties séparées par des points

Un JSON Web Token (JWT, prononcé « jot ») est une chaîne compacte qui transporte des informations signées, par exemple l'identité d'un utilisateur après sa connexion. Il se compose de trois parties encodées en Base64URL (un Base64 sans « + », « / » ni « = ») et séparées par des points : en-tête.contenu.signature.

1. L'en-tête (header) précise l'algorithme de signature (alg) et souvent l'identifiant de la clé (kid).
2. Le contenu (payload) porte les « revendications » (claims), c'est-à-dire les informations transportées.
3. La signature prouve que l'en-tête et le contenu n'ont pas été modifiés depuis leur émission et qu'ils proviennent du détenteur de la clé.

Les revendications standard (claims)

La norme RFC 7519 définit sept revendications « enregistrées », toutes facultatives mais très utilisées :

Les dates exp, nbf et iat sont des « dates numériques » : le nombre de secondes écoulées depuis le 1^er janvier 1970 en UTC, c'est-à-dire un timestamp Unix en secondes. L'outil les convertit en dates lisibles ; vous pouvez aussi les vérifier avec le convertisseur de timestamp. Les serveurs tolèrent généralement quelques dizaines de secondes de décalage d'horloge (leeway) avant de refuser un jeton à peine expiré ou pas encore valide.

Les algorithmes de signature : secret partagé ou clé publique

Avec un algorithme à clé publique, l'émetteur publie ses clés publiques sous forme d'un ensemble de clés au format JWK (RFC 7517), à une adresse bien connue. Les services identifient la bonne clé grâce à la valeur kid de l'en-tête. L'outil accepte une clé publique au format PEM ou JWK et un secret saisi en texte pour les algorithmes HS.

Pour un secret HMAC, l'OWASP recommande au minimum la taille de la sortie du hachage (256 bits pour HS256, 384 pour HS384, 512 pour HS512), tirée d'un générateur aléatoire cryptographique, jamais un mot de passe mémorisable. Pour en fabriquer un, voyez le générateur de mots de passe.

Un JWT est signé, pas chiffré

C'est l'idée reçue la plus dangereuse : le contenu d'un JWT signé est lisible par toute personne qui détient le jeton. L'encodage Base64URL n'est pas un chiffrement : la preuve, l'outil le décode sans aucune clé. La signature garantit seulement l'intégrité et l'origine du contenu, pas sa confidentialité.

• N'y mettez pas de mot de passe, de données de santé, de numéro de carte ni de renseignement personnel inutile. Préférez un identifiant opaque, et laissez le serveur retrouver les détails.
• Pour un contenu qui doit rester confidentiel, la norme prévoit une variante chiffrée, le JWE (RFC 7516). La pratique recommandée est de signer d'abord, puis de chiffrer le jeton signé.
• Ne collez pas de jetons de production d'un compte sensible dans un site tiers. Cet outil travaille entièrement dans votre navigateur, mais la prudence reste de mise : utilisez de préférence des jetons de test ou déjà expirés.

Les vulnérabilités classiques et la liste de contrôle du serveur

Les attaques sur les JWT visent presque toujours une validation incomplète côté serveur. Les recommandations de la RFC 8725 et de l'OWASP se résument ainsi :

1. Imposez la liste des algorithmes acceptés. Ne faites jamais confiance à l'en-tête du jeton pour choisir l'algorithme de vérification. Chaque clé ne doit servir qu'avec un algorithme.
2. Refusez alg: none. Un jeton « non sécurisé » peut être fabriqué par n'importe qui avec le contenu de son choix. L'outil le signale par un avertissement.
3. Évitez la confusion d'algorithmes. Dans l'attaque classique, un jeton déclare HS256 alors que le serveur attend RS256 : si la bibliothèque utilise la clé publique RSA, connue de tous, comme secret HMAC, l'attaquant peut signer un jeton valide. Fixer l'algorithme attendu l'empêche.
4. Vérifiez les revendications : la signature n'est pas suffisante. Contrôlez exp et nbf (avec une tolérance faible), l'émetteur iss et l'audience aud, afin qu'un jeton valide pour un service ne soit pas accepté par un autre.
5. Utilisez des secrets robustes pour les algorithmes HMAC : un secret faible peut être retrouvé par force brute hors ligne à partir d'un seul jeton.
6. Prévoyez la révocation. Un JWT valide le reste jusqu'à son expiration. Retenez des durées de vie courtes, et si une liste de révocation est nécessaire, indexez-la sur l'identifiant jti et l'émetteur plutôt que sur le jeton lui-même.

Enfin, un jeton est envoyé au serveur dans l'en-tête Authorization: Bearer <jeton>. Où le conserver côté navigateur (cookie HttpOnly ou stockage JavaScript) est un choix de sécurité à part entière : un stockage lisible par JavaScript expose le jeton à une faille XSS, un cookie impose de se protéger contre le CSRF. Pour préparer le contenu d'un jeton de test, le formateur JSON valide la syntaxe du contenu.

Questions fréquentes