Hoe werken access tokens en refresh tokens samen?

Question

IT Interview Practice · Accepted Answer

De twee tokens volgen een eenvoudige levenscyclus: een **kortlevend access token** autoriseert elke API-call, en een **langlevend refresh token** maakt stilletjes nieuwe access tokens aan wanneer ze verlopen — zo blijft de gebruiker ingelogd zonder credentials opnieuw in te voeren.

## De flow

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API-call: Authorization: Bearer <access>
     ▼
┌────────────┐  verifieer handtekening + exp   (geen DB-lookup)
│ Resource   │ ──── 200 OK ────▶ (access nog geldig)
│ API        │ ──── 401 ───────▶ (access verlopen)
└────────────┘
     │  3. bij 401: POST /token { refresh }
     ▼
┌────────────┐  verifieer + roteer
│ Auth server│ ──── nieuwe access (+ nieuwe refresh) ────▶ herhaal de call
└────────────┘
```

1. **Login** — de gebruiker authenticeert eenmalig; de server retourneert een **access token** (korte TTL) en een **refresh token** (lange TTL).
2. **API's benaderen** — de client stuurt het access token in `Authorization: Bearer …` bij elke request. De API verifieert het stateless (handtekening + `exp`) en antwoordt — geen session store nodig.
3. **Refreshen bij verloop** — wanneer de API `401` retourneert (of de client ziet dat `exp` nadert), POST de client het **refresh token** naar het `/token`-endpoint van de auth-server en krijgt een vers access token, en herhaalt daarna de oorspronkelijke request. De gebruiker merkt niets.
4. **Uitloggen / intrekken** — de server verwijdert het refresh token of zet het op een denylist; de volgende refresh mislukt en de sessie eindigt (het huidige access token sterft nog steeds vanzelf binnen minuten).

```js
// Client-interceptor: refresh eenmaal bij 401, herhaal dan.
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));   // herhaal
  }
  return res;
}
```

## Refresh-token-rotatie

Best practice is **rotatie**: elke refresh-call retourneert een *nieuw* refresh token en maakt het oude ongeldig. Als een oud (reeds gebruikt) refresh token opnieuw wordt aangeboden, duidt dat op diefstal — de server trekt de hele token-familie in en dwingt opnieuw inloggen af. Dit beperkt de schade van een gestolen refresh token.

## Opslag

- **Refresh token** → `httpOnly`-, `Secure`-, `SameSite`-cookie zodat JavaScript (en dus XSS) het niet kan lezen.
- **Access token** → in het geheugen bewaard op de client; korte levensduur beperkt de blootstelling.
- Zet geen van beide in `localStorage` als je het kunt vermijden — het is leesbaar door elk geïnjecteerd script.

## Waarom het belangrijk is

Deze flow is de ruggengraat van sessiebeheer in moderne SPA's, mobiele apps en API's, dus interviewers verwachten dat je hem van begin tot eind kunt volgen: beide uitgeven bij login, autoriseren met het access token, transparant refreshen bij verloop, en roteren + intrekken voor de veiligheid. De details goed krijgen — stateless verificatie, alleen refreshen bij het token-endpoint, rotatie met hergebruikdetectie, en `httpOnly`-opslag — is het verschil tussen een soepele, veilige sessie en een waarbij één gestolen token een langdurige accountovername betekent.

De flow

Refresh-token-rotatie

Opslag

Waarom het belangrijk is

Gerelateerde vragen