Hvorfor trenger du både et access token og et refresh token?

Question

IT Interview Practice · Accepted Answer

De to tokenene finnes for å løse en direkte konflikt: et access token må **sendes ved hver request** (så det eksponeres mye), men du ønsker også økter som **varer lenge** uten å tvinge fram hyppige innlogginger. Du kan ikke ha begge deler trygt i ett token — så du deler opp jobben.

## De to rollene

- **Access token** — kortlevd (typisk 5–15 minutter), sendt i `Authorization`-headeren ved hvert API-kall. Fordi det overføres konstant, er en lekkasje sannsynlig; å holde det kort betyr at et stjålet et utløper nesten umiddelbart.
- **Refresh token** — langlevd (dager/uker), sendt **kun** til auth-serverens token-endpoint for å skaffe nye access tokens. Det reiser sjelden, kan lagres tryggere, og kan tilbakekalles på serversiden.

```
Login ──▶ access (15m) + refresh (30d)
Hvert API-kall ──▶ send access
Access utløpt ──▶ send refresh ──▶ ny access (+ rotert refresh)
```

## Hvorfor ikke bare ett token?

| | Ett langlevd access token | Access + refresh |
|---|---|---|
| Eksponering | Sendt ved hver request, lever lenge → stort tyverivindu | Access kortlevd; refresh sjelden sendt |
| Tilbakekalling | Vanskelig (stateless JWT kan ikke av-utstedes) | Tilbakekall refresh token; access dør innen minutter |
| UX | Ofte re-innlogging hvis kort | Forblir innlogget uten å taste inn legitimasjon på nytt |
| Skadeomfang ved lekkasje | Stort | Lite (access utløper raskt) |

- **Ett kort access token, ingen refresh** → sikkert, men brukeren logges ut hvert par minutter. Forferdelig UX.
- **Ett langt access token** → flott UX, men et lekket token er gyldig lenge og kan ikke enkelt tilbakekalles.
- **Access + refresh** → kort eksponeringsvindu *og* lange økter. Refresh token er den eneste langlevde hemmeligheten, og den bor på ett trygt sted.

## Hva oppdelingen muliggjør

- **Tilbakekalling til tross for stateless access tokens.** Du kan ikke ugyldiggjøre et JWT-access token før det utløper, men du *kan* slette/avvise refresh tokenet, så økten avsluttes ved neste refresh (innen minutter).
- **Refresh-token-rotasjon** — utsted et nytt refresh token ved hver bruk og oppdag gjenbruk av et gammelt (et tegn på tyveri), og tilbakekall så hele kjeden.
- **Minst eksponering** — den langlevde hemmeligheten (refresh) sendes til nøyaktig ett endpoint, ideelt lagret i en `httpOnly`-cookie, utenfor rekkevidden til XSS.

## Hvorfor det er viktig

Dette er det standard moderne auth-designet, og intervjuere spør om det for å se om du forstår *hvorfor*, ikke bare *hvordan*. Nøkkelinnsikten er avveiningen: statelessness og kort eksponering (access) versus lange økter og tilbakekallbarhet (refresh). Å gjøre det feil — et langlevd access token, ingen rotasjon, refresh lagret i `localStorage` — gjør ett lekket token om til en langvarig kontokompromittering. Å navngi oppdelingen og hva hvert token gir deg, er det en sikkerhetsbevisst ingeniør forventes å vite.

	Ett langlevd access token	Access + refresh
Eksponering	Sendt ved hver request, lever lenge → stort tyverivindu	Access kortlevd; refresh sjelden sendt
Tilbakekalling	Vanskelig (stateless JWT kan ikke av-utstedes)	Tilbakekall refresh token; access dør innen minutter
UX	Ofte re-innlogging hvis kort	Forblir innlogget uten å taste inn legitimasjon på nytt
Skadeomfang ved lekkasje	Stort	Lite (access utløper raskt)

De to rollene

Hvorfor ikke bare ett token?

Hva oppdelingen muliggjør

Hvorfor det er viktig

Relaterte spørsmål