Hvordan fungerer access tokens og refresh tokens sammen?

Question

IT Interview Practice · Accepted Answer

De to tokenene følger en enkel livssyklus: et **kortlevd access token** autoriserer hvert API-kall, og et **langlevd refresh token** lager i det stille nye access tokens når de utløper — så brukeren forblir innlogget uten å taste inn legitimasjon på nytt.

## Flyten

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API-kall: Authorization: Bearer <access>
     ▼
┌────────────┐  verifiser signatur + exp   (ingen DB-oppslag)
│ Resource   │ ──── 200 OK ────▶ (access fortsatt gyldig)
│ API        │ ──── 401 ───────▶ (access utløpt)
└────────────┘
     │  3. ved 401: POST /token { refresh }
     ▼
┌────────────┐  verifiser + roter
│ Auth server│ ──── nytt access (+ nytt refresh) ────▶ prøv kallet på nytt
└────────────┘
```

1. **Login** — brukeren autentiserer én gang; serveren returnerer et **access token** (kort TTL) og et **refresh token** (lang TTL).
2. **Tilgang til API-er** — klienten sender access tokenet i `Authorization: Bearer …` ved hver request. API-et verifiserer det stateless (signatur + `exp`) og svarer — ingen session store nødvendig.
3. **Refresh ved utløp** — når API-et returnerer `401` (eller klienten ser at `exp` nærmer seg), sender klienten en POST med **refresh tokenet** til auth-serverens `/token`-endpoint og får et ferskt access token, og prøver deretter den opprinnelige requesten på nytt. Brukeren merker ingenting.
4. **Utlogging / tilbakekalling** — serveren sletter eller denylister refresh tokenet; neste refresh feiler og økten avsluttes (det gjeldende access tokenet dør fortsatt av seg selv innen minutter).

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

## Refresh-token-rotasjon

Beste praksis er **rotasjon**: hvert refresh-kall returnerer et *nytt* refresh token og ugyldiggjør det gamle. Hvis et gammelt (allerede brukt) refresh token presenteres på nytt, signaliserer det tyveri — serveren tilbakekaller hele token-familien og tvinger fram ny innlogging. Dette begrenser skaden av et stjålet refresh token.

## Lagring

- **Refresh token** → `httpOnly`-, `Secure`-, `SameSite`-cookie slik at JavaScript (og dermed XSS) ikke kan lese det.
- **Access token** → holdt i minnet på klienten; kort levetid begrenser eksponeringen.
- Legg aldri noen av dem i `localStorage` hvis du kan unngå det — det er lesbart av ethvert injisert skript.

## Hvorfor det er viktig

Denne flyten er ryggraden i økthåndtering i moderne SPA-er, mobilapper og API-er, så intervjuere forventer at du kan spore den fra ende til ende: utsted begge ved login, autoriser med access tokenet, refresh transparent ved utløp, og roter + tilbakekall for sikkerhet. Å få detaljene riktig — stateless verifisering, refresh kun ved token-endpoint, rotasjon med gjenbruksdeteksjon, og `httpOnly`-lagring — er forskjellen mellom en smidig, sikker økt og en der ett stjålet token betyr en langvarig kontoovertakelse.

Flyten

Refresh-token-rotasjon

Lagring

Hvorfor det er viktig

Relaterte spørsmål