Hur fungerar access tokens och refresh tokens tillsammans?

Question

IT Interview Practice · Accepted Answer

De två tokens följer en enkel livscykel: en **kortlivad access token** auktoriserar varje API-anrop, och en **långlivad refresh token** präglar tyst nya access tokens när de löper ut — så användaren förblir inloggad utan att ange uppgifter på nytt.

## Flödet

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API-anrop: Authorization: Bearer <access>
     ▼
┌────────────┐  verifiera signatur + exp   (ingen DB-uppslagning)
│ Resource   │ ──── 200 OK ────▶ (access fortfarande giltig)
│ API        │ ──── 401 ───────▶ (access utgången)
└────────────┘
     │  3. vid 401: POST /token { refresh }
     ▼
┌────────────┐  verifiera + rotera
│ Auth server│ ──── ny access (+ ny refresh) ────▶ försök anropet igen
└────────────┘
```

1. **Login** — användaren autentiserar en gång; servern returnerar en **access token** (kort TTL) och en **refresh token** (lång TTL).
2. **Anropa API:er** — klienten skickar access token i `Authorization: Bearer …` vid varje request. API:et verifierar den statelessly (signatur + `exp`) och svarar — ingen session-lagring behövs.
3. **Refresh vid utgång** — när API:et returnerar `401` (eller klienten ser att `exp` är nära) POST:ar klienten **refresh token** till auth-serverns `/token`-endpoint och får en färsk access token, försöker sedan om den ursprungliga requesten. Användaren märker ingenting.
4. **Logout / återkalla** — servern raderar eller denylistar refresh token; nästa refresh misslyckas och sessionen slutar (den nuvarande access token dör ändå av sig själv inom minuter).

```js
// Client interceptor: refresh en gång vid 401, försök sedan 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));   // försök igen
  }
  return res;
}
```

## Refresh token-rotation

Bästa praxis är **rotation**: varje refresh-anrop returnerar en *ny* refresh token och ogiltigförklarar den gamla. Om en gammal (redan använd) refresh token presenteras igen signalerar det stöld — servern återkallar hela token-familjen och tvingar fram ominloggning. Detta begränsar skadan av en stulen refresh token.

## Lagring

- **Refresh token** → `httpOnly`-, `Secure`-, `SameSite`-cookie så att JavaScript (och därmed XSS) inte kan läsa den.
- **Access token** → hålls i minnet på klienten; kort liv begränsar exponering.
- Lägg aldrig någon av dem i `localStorage` om du kan undvika det — det är läsbart av vilket injicerat skript som helst.

## Varför det är viktigt

Detta flöde är ryggraden i sessionshantering i moderna SPA:er, mobilappar och API:er, så intervjuare förväntar sig att du spårar det från början till slut: utfärda båda vid login, auktorisera med access token, uppdatera transparent vid utgång, och rotera + återkalla för säkerhet. Att få detaljerna rätt — stateless verifiering, refresh endast vid token-endpoint, rotation med återanvändningsdetektering, och `httpOnly`-lagring — är skillnaden mellan en smidig, säker session och en där en enda stulen token betyder ett långlivat kontoövertagande.

Flödet

Refresh token-rotation

Lagring

Varför det är viktigt

Relaterade frågor