Waarom heb je zowel een access token als een refresh token nodig?

Question

IT Interview Practice · Accepted Answer

De twee tokens bestaan om een direct conflict op te lossen: een access token moet **bij elke request meegestuurd** worden (dus wordt hij veel blootgesteld), maar je wilt ook sessies die **lang meegaan** zonder frequent inloggen af te dwingen. Je kunt beide niet veilig in één token hebben — dus splits je de taak.

## De twee rollen

- **Access token** — kortlevend (meestal 5–15 minuten), meegestuurd in de `Authorization`-header bij elke API-call. Omdat hij voortdurend wordt verzonden, is een lek waarschijnlijk; hem kort houden betekent dat een gestolen exemplaar bijna onmiddellijk verloopt.
- **Refresh token** — langlevend (dagen/weken), **alleen** verzonden naar het token-endpoint van de auth-server om nieuwe access tokens te verkrijgen. Hij reist zelden, kan veiliger worden opgeslagen en kan server-side worden ingetrokken.

```
Login ──▶ access (15m) + refresh (30d)
Elke API-call ──▶ stuur access
Access verlopen ──▶ stuur refresh ──▶ nieuwe access (+ geroteerde refresh)
```

## Waarom niet gewoon één token?

| | Eén langlevend access token | Access + refresh |
|---|---|---|
| Blootstelling | Bij elke request verzonden, leeft lang → groot diefstalvenster | Access kortlevend; refresh zelden verzonden |
| Intrekking | Moeilijk (stateless JWT kan niet worden 'on-uitgegeven') | Trek het refresh token in; access sterft binnen minuten |
| UX | Vaak opnieuw inloggen als kort | Blijft ingelogd zonder credentials opnieuw in te voeren |
| Impactstraal van een lek | Groot | Klein (access verloopt snel) |

- **Eén kort access token, geen refresh** → veilig, maar de gebruiker wordt om de paar minuten uitgelogd. Vreselijke UX.
- **Eén lang access token** → geweldige UX, maar een gelekt token is lang geldig en kan niet gemakkelijk worden ingetrokken.
- **Access + refresh** → kort blootstellingsvenster *en* lange sessies. Het refresh token is het enige langlevende geheim, en het leeft op één veilige plek.

## Wat de splitsing mogelijk maakt

- **Intrekking ondanks stateless access tokens.** Je kunt een JWT-access token niet ongeldig maken voordat het verloopt, maar je *kunt* het refresh token verwijderen/weigeren, dus de sessie eindigt bij de volgende refresh (binnen minuten).
- **Refresh-token-rotatie** — geef bij elk gebruik een nieuw refresh token uit en detecteer hergebruik van een oud exemplaar (een teken van diefstal), en trek dan de hele keten in.
- **Minste blootstelling** — het langlevende geheim (refresh) wordt naar precies één endpoint gestuurd, idealiter opgeslagen in een `httpOnly`-cookie, buiten bereik van XSS.

## Waarom het belangrijk is

Dit is het standaard moderne auth-ontwerp, en interviewers vragen het om te zien of je het *waarom* begrijpt, niet alleen het *hoe*. Het kerninzicht is de trade-off: statelessness en korte blootstelling (access) versus lange sessies en intrekbaarheid (refresh). Het fout doen — een langlevend access token, geen rotatie, refresh opgeslagen in `localStorage` — verandert één gelekt token in een langdurige accountcompromittering. De splitsing benoemen en wat elk token je oplevert, is wat van een beveiligingsbewuste engineer wordt verwacht.

	Eén langlevend access token	Access + refresh
Blootstelling	Bij elke request verzonden, leeft lang → groot diefstalvenster	Access kortlevend; refresh zelden verzonden
Intrekking	Moeilijk (stateless JWT kan niet worden 'on-uitgegeven')	Trek het refresh token in; access sterft binnen minuten
UX	Vaak opnieuw inloggen als kort	Blijft ingelogd zonder credentials opnieuw in te voeren
Impactstraal van een lek	Groot	Klein (access verloopt snel)

De twee rollen

Waarom niet gewoon één token?

Wat de splitsing mogelijk maakt

Waarom het belangrijk is

Gerelateerde vragen