Comment les access tokens et les refresh tokens fonctionnent-ils ensemble ?

Question

IT Interview Practice · Accepted Answer

Les deux tokens suivent un cycle de vie simple : un **access token à courte durée de vie** autorise chaque appel API, et un **refresh token à longue durée de vie** fabrique silencieusement de nouveaux access tokens à leur expiration — ainsi l'utilisateur reste connecté sans ressaisir ses identifiants.

## Le flux

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API call: Authorization: Bearer <access>
     ▼
┌────────────┐  verify signature + exp   (no DB lookup)
│ Resource   │ ──── 200 OK ────▶ (access still valid)
│ API        │ ──── 401 ───────▶ (access expired)
└────────────┘
     │  3. on 401: POST /token { refresh }
     ▼
┌────────────┐  verify + rotate
│ Auth server│ ──── new access (+ new refresh) ────▶ retry the call
└────────────┘
```

1. **Login** — l'utilisateur s'authentifie une fois ; le serveur renvoie un **access token** (TTL court) et un **refresh token** (TTL long).
2. **Appels API** — le client envoie l'access token dans `Authorization: Bearer …` à chaque requête. L'API le vérifie de façon stateless (signature + `exp`) et répond — aucun stockage de session nécessaire.
3. **Refresh à l'expiration** — quand l'API renvoie `401` (ou que le client voit que `exp` est proche), le client POST le **refresh token** au endpoint `/token` du serveur d'authentification et obtient un access token frais, puis réessaie la requête d'origine. L'utilisateur ne remarque rien.
4. **Déconnexion / révocation** — le serveur supprime ou met sur liste de refus le refresh token ; le prochain refresh échoue et la session se termine (l'access token courant meurt de toute façon de lui-même en quelques minutes).

```js
// Intercepteur client : refresh une fois sur 401, puis réessayer.
async function apiFetch(url, opts = {}) {
  let res = await fetch(url, withAuth(opts, accessToken));
  if (res.status === 401) {
    accessToken = await refreshAccessToken(refreshToken); // POST /token
    res = await fetch(url, withAuth(opts, accessToken));   // réessayer
  }
  return res;
}
```

## Rotation du refresh token

La bonne pratique est la **rotation** : chaque appel de refresh renvoie un *nouveau* refresh token et invalide l'ancien. Si un ancien refresh token (déjà utilisé) est présenté à nouveau, cela signale un vol — le serveur révoque toute la famille de tokens et force une reconnexion. Cela limite les dégâts d'un refresh token volé.

## Stockage

- **Refresh token** → cookie `httpOnly`, `Secure`, `SameSite` pour que JavaScript (et donc le XSS) ne puisse pas le lire.
- **Access token** → conservé en mémoire côté client ; sa courte durée de vie limite l'exposition.
- Ne mettez jamais l'un ou l'autre dans `localStorage` si vous pouvez l'éviter — il est lisible par n'importe quel script injecté.

## Pourquoi c'est important

Ce flux est l'épine dorsale de la gestion de session dans les SPA modernes, les apps mobiles et les API, donc les recruteurs attendent que vous le traciez de bout en bout : émettre les deux à la connexion, autoriser avec l'access token, rafraîchir de façon transparente à l'expiration, et effectuer rotation + révocation pour la sécurité. Bien maîtriser les détails — vérification stateless, refresh uniquement au endpoint de tokens, rotation avec détection de réutilisation, et stockage `httpOnly` — fait la différence entre une session fluide et sécurisée et une où un seul token volé signifie une prise de contrôle de compte à long terme.

Le flux

Rotation du refresh token

Stockage

Pourquoi c'est important

Questions connexes