Décodeur JWT

Analysez vos JSON Web Tokens : header, payload, claims et validité.

Token JWT

Guide complet des JSON Web Tokens

Anatomie d'un JWT

Après des années à implémenter l'authentification JWT dans des applications, je peux affirmer que comprendre leur structure est fondamental. Un JWT se compose de trois parties séparées par des points : le header (algorithme de signature), le payload (données/claims), et la signature (vérification d'intégrité). Chaque partie est encodée en Base64URL : pas chiffrée, juste encodée.

Structure détaillée

Header (JOSE)

Contient le type de token (JWT) et l'algorithme de signature (HS256, RS256, etc.). Le header informe le récepteur comment vérifier la signature.

Payload (Claims)

Les données transportées. Claims réservés (iss, exp, sub, aud) et claims personnalisés. Attention : visible par tous, ne jamais inclure de secrets.

Signature

Hash du header + payload avec une clé secrète. Garantit que le token n'a pas été modifié. Sans la clé, impossible de générer une signature valide.

Claims standard (réservés)

  • iss (issuer) : Identifie qui a émis le token (votre serveur d'authentification)
  • sub (subject) : Le sujet du token, généralement l'ID utilisateur
  • aud (audience) : Les destinataires prévus du token
  • exp (expiration) : Timestamp Unix après lequel le token est invalide
  • iat (issued at) : Timestamp de création du token
  • nbf (not before) : Token invalide avant cette date
  • jti (JWT ID) : Identifiant unique pour prévenir la réutilisation

Bonnes pratiques de sécurité

  • Utiliser des durées d'expiration courtes (15 min à 1 heure) avec refresh tokens
  • Ne JAMAIS stocker de données sensibles dans le payload : il est lisible par tous
  • Toujours vérifier la signature côté serveur avant de faire confiance aux claims
  • Préférer RS256 (asymétrique) à HS256 pour les systèmes distribués
  • Implémenter une blacklist pour l'invalidation anticipée si nécessaire
  • Stocker les JWT en httpOnly cookies plutôt que localStorage contre XSS

Questions fréquentes

Un JWT décodé ici est-il sécurisé ?

Le décodage s'effectue entièrement dans votre navigateur : rien n'est envoyé à un serveur. Cependant, rappelez-vous que le payload d'un JWT n'est pas chiffré. N'importe qui ayant accès au token peut le décoder. La signature garantit l'intégrité (non-modification), pas la confidentialité. Pour les tokens de production, utilisez des outils locaux.

Quelle différence entre HS256 et RS256 ?

HS256 utilise une clé secrète symétrique : la même clé signe et vérifie. Simple mais la clé doit être partagée avec tous les services qui vérifient. RS256 utilise une paire clé privée/publique : seul l'émetteur détient la clé privée, tout le monde peut vérifier avec la clé publique. Idéal pour les architectures microservices.

Comment invalider un JWT avant expiration ?

C'est le talon d'Achille des JWT : ils sont stateless par conception. Options : 1) Blacklist en base de données (vérifie le jti à chaque requête) : perd l'avantage stateless. 2) Durées très courtes avec refresh tokens révocables. 3) Versionner les tokens par utilisateur (user_version dans le payload). 4) Changer la clé de signature : invalide TOUS les tokens.

Où stocker un JWT côté client ?

Sujet débattu. localStorage est vulnérable aux attaques XSS (le JS malveillant peut lire le token). Les cookies httpOnly + Secure + SameSite=Strict sont protégés contre XSS mais exposés au CSRF (atténuable avec des tokens CSRF). Ma recommandation : cookies httpOnly pour les applications web classiques, localStorage avec CSP strict pour les SPA si nécessaire.

Quelle durée d'expiration choisir ?

Compromis entre sécurité et UX. Access tokens : 15 minutes à 1 heure : limite la fenêtre d'exploitation si volé. Refresh tokens : 7-30 jours, stockés de façon sécurisée, révocables. Pour les applications sensibles (bancaires), 5-15 minutes max. Pour les apps grand public, 1 heure est acceptable. Toujours implémenter le refresh transparent.

Peut-on modifier un JWT ?

On peut modifier le payload, mais la signature ne correspondra plus : le serveur rejettera le token. C'est justement le but de la signature. Attention à l'algorithme "none" : certaines bibliothèques mal configurées l'acceptent, permettant de supprimer la signature. Toujours vérifier l'algorithme attendu côté serveur, ne jamais faire confiance au header du token.