Hvordan fungerer access tokens og refresh tokens sammen?

Question

IT Interview Practice · Accepted Answer

De to tokens følger en simpel livscyklus: et **kortlivet access token** autoriserer hvert API-kald, og et **langlivet refresh token** udsteder i stilhed nye access tokens, når de udløber — så brugeren forbliver logget ind uden at genindtaste legitimationsoplysninger.

## Flowet

```
┌─────────┐  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** — brugeren autentificerer sig én gang; serveren returnerer et **access token** (kort TTL) og et **refresh token** (lang TTL).
2. **Adgang til API'er** — klienten sender access-tokenet i `Authorization: Bearer …` ved hver request. API'et verificerer det stateless (signatur + `exp`) og svarer — ingen session-store nødvendig.
3. **Refresh ved udløb** — når API'et returnerer `401` (eller klienten ser, at `exp` er nær), POST'er klienten **refresh-tokenet** til auth-serverens `/token`-endpoint og får et friskt access token, hvorefter den prøver den oprindelige request igen. Brugeren mærker intet.
4. **Logout / tilbagekald** — serveren sletter eller denylister refresh-tokenet; næste refresh fejler, og sessionen slutter (det nuværende access token dør stadig af sig selv inden for minutter).

```js
// Klient-interceptor: refresh én gang ved 401, prøv derefter igen.
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));   // prøv igen
  }
  return res;
}
```

## Refresh token-rotation

Bedste praksis er **rotation**: hvert refresh-kald returnerer et *nyt* refresh token og ugyldiggør det gamle. Hvis et gammelt (allerede brugt) refresh token præsenteres igen, signalerer det tyveri — serveren tilbagekalder hele token-familien og fremtvinger gen-login. Dette begrænser skaden fra et stjålet refresh token.

## Opbevaring

- **Refresh token** → `httpOnly`-, `Secure`-, `SameSite`-cookie, så JavaScript (og dermed XSS) ikke kan læse det.
- **Access token** → holdt i hukommelsen på klienten; kort levetid begrænser eksponering.
- Læg aldrig nogen af dem i `localStorage`, hvis du kan undgå det — det kan læses af ethvert injiceret script.

## Hvorfor det betyder noget

Dette flow er rygraden i session-håndtering i moderne SPA'er, mobilapps og API'er, så interviewere forventer, at du kan spore det fra ende til anden: udsted begge ved login, autorisér med access-tokenet, refresh transparent ved udløb, og rotér + tilbagekald for sikkerheds skyld. At få detaljerne rigtige — stateless verifikation, refresh kun ved token-endpointet, rotation med genbrugsdetektion og `httpOnly`-opbevaring — er forskellen mellem en glat, sikker session og en, hvor et enkelt stjålet token betyder en langlivet kontoovertagelse.

Flowet

Refresh token-rotation

Opbevaring

Hvorfor det betyder noget

Relaterede spørgsmål