Comment décoder un JWT sans envoyer votre token sur le serveur d'un inconnu

Les JWT sont partout. Chaque fois que vous vous connectez à une application web, une API vous émet un JSON Web Token, et ce token porte votre identité, vos permissions et souvent quelques informations personnelles dans son payload. Le format lui-même était stable depuis une décennie, puis une série d’activités en 2024-2025 — la RFC 8725 (meilleures pratiques actuelles pour les JWT) est devenue une exigence stricte pour les nouvelles specs, le débat « les JWT sont mauvais » a ravivé à cause du dimensionnement des sessions, et plusieurs grands fournisseurs sont passés à des tokens opaques pour une utilisation dans le navigateur. Le résultat : plus de développeurs que jamais inspectent les tokens à la main. Quand quelque chose ne va pas — votre session expire au mauvais moment, une API rejette un token que vous pensiez valide, un collègue dit « qu’est-ce qu’il y a dans le JWT ? » — la plupart des développeurs collent d’abord le token dans un décodeur en ligne.

Le problème : la plupart de ces décodeurs envoient votre token à un serveur. Le token lui-même n’est pas un secret (c’est juste du JSON encodé en base64), mais le contenu du payload l’est souvent : un ID utilisateur, un email, parfois un ID de session, parfois une liste de permissions. Si votre service utilise des JWT pour communiquer avec d’autres services internes, le payload pourrait même inclure des noms de services internes ou des feature flags.

Un token collé dans un décodeur tiers est une petite fuite d’information. La plupart du temps, ça n’a pas d’importance. Mais le principe est important : vous devriez pouvoir inspecter un token sans faire confiance à l’infrastructure de quelqu’un d’autre.

À quoi ressemble réellement un JWT

Un JWT est trois chaînes encodées en base64url, séparées par des points :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Les trois parties sont l’en-tête, le payload et la signature. Décodez les deux premières et vous obtenez du JSON :

// Header
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload
{
  "sub": "12345",
  "name": "Alice",
  "iat": 1516239022
}

La signature est un hash cryptographique qui prouve que le token a été émis par quelqu’un qui connaît le secret. N’importe qui peut décoder le payload — ce n’est pas la limite de sécurité. La limite de sécurité est de savoir si vous pouvez vérifier la signature.

La distinction entre vérification et décodage

C’est là que beaucoup de développeurs se trompent. Décoder n’est pas vérifier. Un décodeur décode simplement le JSON en base64 pour que vous puissiez le lire. N’importe qui peut faire cela, et cela ne prouve pas que le token est authentique. La vérification est l’action de vérifier la signature par rapport à un secret connu pour confirmer que le token n’a pas été altéré.

• Pour déboguer le contenu d’un token (quelles affirmations contient-il, quand expire-t-il), le décodage suffit.
• Pour authentifier un utilisateur, vous avez besoin de la vérification, et elle doit se produire sur un serveur en lequel vous avez confiance.

La plupart des outils de décodage en ligne ne font que décoder. Ils affichent l’en-tête et le payload mais ne demandent jamais votre secret — parce qu’ils ne vérifient pas, ils vous montrent simplement ce qu’il y a dans le token.

Comment décoder localement

Vous n’avez pas besoin d’un outil tiers pour cela. Un JWT n’est que trois chaînes base64url. Ouvrez un terminal :

echo 'eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTUxNjIzOTAyMn0' | tr '_-' '/+' | base64 -d

C’est le payload. L’en-tête est le premier segment, même astuce.

Si vous préférez ne pas mémoriser le manège tr '_-' '/+', le décodeur JWT sur DevSpeedTools fait la même chose dans le navigateur. Pas de requête réseau, pas de téléchargement, pas de journal. Ouvrez DevTools → Réseau, collez un token et confirmez vous-même que rien ne quitte votre machine.

Quand vous avez réellement besoin de vérification

Si vous essayez de déboguer un problème d’authentification et que vous devez savoir si le token est valide (pas seulement ce qu’il contient), vous devez vérifier la signature. La vérification doit se faire avec le même secret ou la même clé publique que votre serveur d’authentification. Cela signifie qu’elle doit se produire sur une infrastructure que vous contrôlez.

Quelques options de vérification qui n’impliquent pas de coller votre secret sur un site web :

• En Node.js : jsonwebtoken.verify(token, process.env.JWT_SECRET).
• En Python : jwt.decode(token, key, algorithms=['HS256']).
• En Go : token, err := jwt.Parse(tokenString, keyFunc).
• CLI : jwt-cli (Rust) ou pyjwt avec une ligne de commande.

Si vous avez besoin d’un vérificateur en ligne pour une raison ou une autre, cherchez-en un qui indique explicitement qu’il s’exécute dans le navigateur (le code source est généralement visible). Les outils honnêtes le disent. Pour les autres, vous devriez supposer qu’ils téléchargent votre token vers un serveur.

L’erreur « invalid signature »

Une raison courante pour laquelle les développeurs se retrouvent sur un décodeur est l’erreur invalid signature. Ce message fait deux choses :

1. Vous dire que le token a été signé avec un secret différent de celui que vous utilisez pour vérifier.
2. Vous dire que le token a peut-être été altéré.

Ou — et c’est ce que la plupart des gens manquent — le token a peut-être expiré. Vérifiez l’affirmation exp dans le payload. Si le timestamp Unix actuel est passé exp, le token est invalide. Certaines bibliothèques lèvent invalid signature pour les tokens expirés, ce qui est trompeur.

Le décodeur JWT affiche la valeur exp aux côtés du reste du payload pour que vous puissiez repérer les tokens expirés en un coup d’œil. Il en va de même pour nbf (not before), iat (issued at) et aud (audience) — tous utiles pour le débogage.

Le résumé

Les décodeurs JWT sont utiles. Ils sont aussi un endroit où les développeurs se montrent négligents en collant des tokens de production. Une option par défaut plus sûre :

• Utilisez un décodeur local ou dans le navigateur pour une inspection rapide. Pas de téléchargement, pas de fuite.
• Utilisez un CLI ou votre propre code pour la vérification. Ne collez jamais un secret sur un site web.
• Vérifiez d’abord les affirmations standard — exp expiré est la cause de la plupart des problèmes « mon token a soudainement cessé de fonctionner ».

Le token n’est pas un secret. Le contenu du token l’est souvent. Traitez-le en conséquence.