Comment fonctionne un JSON Web Token (JWT) ?

Question

IT Interview Practice · Accepted Answer

Un **JSON Web Token (JWT)** est un jeton compact, sûr pour les URL et autonome qui porte des revendications (claims) sur un utilisateur. Le serveur le signe une fois ; ensuite il peut **vérifier** le jeton à chaque requête sans consultation de base de données — c'est ce qui rend l'authentification basée sur JWT *sans état (stateless)*.

## Structure : trois parties base64url

Un JWT est `header.payload.signature`, trois segments encodés en base64url joints par des points :

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (revendications)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** — l'algorithme de signature, par ex. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — les **revendications (claims)** : les standard comme `sub` (subject/id utilisateur), `exp` (expiration), `iat` (émis à), `iss` (émetteur), plus tout champ personnalisé (`role`, `email`).
- **Signature** — calculée sur le header et le payload avec un secret ou une clé privée.

> Le payload est **encodé, pas chiffré**. N'importe qui peut le décoder en base64 et le lire, donc ne mettez jamais de mots de passe ou de secrets dans un JWT.

## Comment fonctionnent la signature et la vérification

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256** (symétrique) : le même secret signe et vérifie. Simple, mais chaque vérificateur doit détenir le secret.
- **RS256** (asymétrique) : une **clé privée** signe, une **clé publique** vérifie. Le serveur d'authentification garde la clé privée ; les autres services vérifient avec la clé publique et ne peuvent jamais forger de jetons.

À chaque requête, le serveur recalcule la signature sur le header+payload reçu et la compare. S'ils correspondent et que `exp` est dans le futur, le jeton est de confiance — aucun magasin de session nécessaire.

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // lève une erreur si altéré ou expiré
  // claims.sub === "123"
} catch (e) {
  // rejeter : invalide ou expiré
}
```

## La partie difficile : la révocation

Parce que la vérification est sans état, vous **ne pouvez pas** invalider un jeton avant son expiration simplement en le « supprimant » côté serveur. Atténuations courantes :

- Gardez les jetons d'accès **à courte durée de vie** (5–15 min) et associez-les à un **refresh token** de plus longue durée.
- Maintenez une petite **liste de refus (denylist)** d'identifiants de jetons révoqués (`jti`) pour la déconnexion/compromission — cela réintroduit un peu d'état.
- Faites tourner les clés de signature.

## Compromis de stockage

| Stockage | Avantage | Inconvénient |
|---|---|---|
| Cookie `httpOnly` | Non lisible par JS (plus sûr contre le XSS) | Nécessite une protection CSRF |
| `localStorage` | Simple, pas de CSRF | Exposé au XSS |

## Pourquoi c'est important

Les JWT alimentent l'authentification sans état à travers les API, les microservices et les SPA — un service peut faire confiance à une requête en vérifiant une signature seule, sans magasin de session partagé. Mais cette même absence d'état est le piège classique d'entretien : les jetons ne peuvent pas être révoqués facilement, le payload est lisible, et la confusion d'`alg` ou une vérification d'expiration manquante sont de vraies vulnérabilités. Savoir exactement ce que la signature protège, et ce qu'elle ne protège pas, est essentiel pour utiliser les JWT en toute sécurité.

Stockage	Avantage	Inconvénient
Cookie `httpOnly`	Non lisible par JS (plus sûr contre le XSS)	Nécessite une protection CSRF
`localStorage`	Simple, pas de CSRF	Exposé au XSS

Structure : trois parties base64url

Comment fonctionnent la signature et la vérification

La partie difficile : la révocation

Compromis de stockage

Pourquoi c'est important

Questions connexes