Qu'est-ce qu'un JWT ?

Un JSON Web Token (JWT, prononcé « jot ») est un standard ouvert (RFC 7519) qui définit un format compact et autonome pour transmettre des informations de manière sécurisée entre deux parties sous forme d'objet JSON. Ces informations peuvent être vérifiées et approuvées car elles sont signées numériquement.

Les JWT sont omniprésents dans le développement web moderne : authentification, autorisation, échange d'informations entre microservices, tokens API... Comprendre leur fonctionnement est essentiel pour tout développeur backend ou fullstack.

Anatomie d'un JWT

Un JWT se compose de trois parties séparées par des points (.) :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ik1hcmMgTGVmw6h2cmUiLCJpYXQiOjE3MTk4MzIwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header (en-tête)

L'en-tête contient le type de token et l'algorithme de signature utilisé :

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

Les algorithmes les plus courants sont HS256 (HMAC-SHA256, symétrique) et RS256 (RSA-SHA256, asymétrique). Le choix dépend de votre architecture — nous y reviendrons.

2. Payload (charge utile)

Le payload contient les claims — les déclarations sur l'utilisateur et les métadonnées. Il existe trois types de claims :

{
  "sub": "1234567890",       // Registered claim - sujet
  "name": "Marc Lefèvre",   // Public claim
  "iat": 1719832000,        // Registered claim - issued at
  "exp": 1719918400,        // Registered claim - expiration
  "role": "admin"           // Private claim
}

Claims réservés importants :

  • iss (issuer) — qui a émis le token
  • sub (subject) — l'identifiant de l'utilisateur
  • exp (expiration) — timestamp Unix d'expiration
  • iat (issued at) — timestamp Unix de création
  • aud (audience) — le destinataire prévu

3. Signature

La signature vérifie que le message n'a pas été altéré. Pour HS256, elle est calculée ainsi :

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

Utilisez notre décodeur JWT pour visualiser instantanément les trois parties de n'importe quel token.

HS256 vs RS256 : quel algorithme choisir ?

HS256 (symétrique)

Une seule clé secrète est partagée entre l'émetteur et le vérificateur. C'est simple, rapide, et adapté aux architectures monolithiques où le même serveur crée et vérifie les tokens.

RS256 (asymétrique)

Utilise une paire clé privée / clé publique. Le serveur d'authentification signe avec la clé privée, et n'importe quel service peut vérifier avec la clé publique. C'est le choix recommandé pour les architectures microservices et les scénarios où plusieurs services doivent valider les tokens.

JWT en pratique : authentification

Le flux d'authentification JWT typique se déroule en 4 étapes :

  1. Login — l'utilisateur envoie ses identifiants (email + mot de passe)
  2. Génération — le serveur vérifie les identifiants et génère un JWT signé
  3. Stockage — le client stocke le JWT (cookie HttpOnly ou mémoire)
  4. Requêtes — chaque requête inclut le JWT dans l'en-tête Authorization: Bearer <token>

Exemple Node.js avec jsonwebtoken

const jwt = require('jsonwebtoken');

// Génération du token
const token = jwt.sign(
  { sub: user.id, role: user.role },
  process.env.JWT_SECRET,
  { expiresIn: '1h', issuer: 'mivkit.com' }
);

// Vérification du token
try {
  const decoded = jwt.verify(token, process.env.JWT_SECRET);
  console.log(decoded.sub); // ID utilisateur
} catch (err) {
  if (err.name === 'TokenExpiredError') {
    // Token expiré — demander un refresh
  }
}

Les erreurs de sécurité à éviter

❌ Stocker des données sensibles dans le payload

Le payload est encodé en Base64, pas chiffré. N'importe qui peut le décoder (essayez avec notre outil Base64). Ne mettez jamais de mots de passe, numéros de carte ou données personnelles sensibles dans un JWT.

❌ Ignorer l'expiration

Un JWT sans exp est valide indéfiniment. Utilisez toujours une durée d'expiration courte (15 minutes à 1 heure pour les access tokens) et un mécanisme de refresh token.

❌ Utiliser l'algorithme "none"

Certaines bibliothèques acceptent "alg": "none" — un token sans signature. Vérifiez toujours que votre bibliothèque rejette explicitement cet algorithme.

❌ Stocker le JWT dans localStorage

Le localStorage est accessible via JavaScript, ce qui expose le token aux attaques XSS. Préférez un cookie HttpOnly + Secure + SameSite=Strict.

Refresh tokens : la bonne pratique

Le pattern recommandé utilise deux tokens :

  • Access token (JWT, courte durée : 15 min) — envoyé avec chaque requête API
  • Refresh token (opaque, longue durée : 7 jours) — stocké en cookie HttpOnly, utilisé uniquement pour obtenir un nouvel access token

Quand l'access token expire, le client envoie automatiquement le refresh token au serveur qui émet un nouvel access token. Si le refresh token est compromis, il peut être révoqué côté serveur (contrairement à un JWT classique).

JWT vs Sessions : quand utiliser quoi ?

Utilisez les JWT pour les API stateless, les architectures microservices, l'authentification entre domaines (SSO), et les applications mobiles.

Utilisez les sessions pour les applications web monolithiques, quand vous avez besoin de révocation instantanée, ou quand la simplicité prime sur la scalabilité.

Conclusion

Les JWT sont un outil puissant mais qui nécessite une bonne compréhension pour être utilisé de manière sécurisée. Respectez les bonnes pratiques — expiration courte, stockage sécurisé, algorithme fort, et refresh tokens — et vous aurez un système d'authentification robuste et scalable. Utilisez notre décodeur JWT en ligne pour inspecter et déboguer vos tokens pendant le développement.

JWT Authentification OAuth Sécurité