Jak spolu access tokeny a refresh tokeny fungují?

Question

IT Interview Practice · Accepted Answer

Dva tokeny sledují jednoduchý životní cyklus: **krátce žijící access token** autorizuje každé volání API a **dlouho žijící refresh token** tiše razí nové access tokeny, když vyprší — takže uživatel zůstává přihlášen bez opětovného zadávání údajů.

## Průběh

```
┌─────────┐  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** — uživatel se ověří jednou; server vrátí **access token** (krátké TTL) a **refresh token** (dlouhé TTL).
2. **Přístup k API** — klient posílá access token v `Authorization: Bearer …` při každém požadavku. API ho ověří bezstavově (podpis + `exp`) a odpoví — není potřeba úložiště relací.
3. **Obnovení při vypršení** — když API vrátí `401` (nebo klient vidí, že `exp` je blízko), klient POSTne **refresh token** na endpoint `/token` autentizačního serveru a získá čerstvý access token, poté zopakuje původní požadavek. Uživatel si ničeho nevšimne.
4. **Odhlášení / odvolání** — server smaže refresh token nebo ho zařadí na denylist; příští obnovení selže a relace skončí (aktuální access token stejně sám odumře během minut).

```js
// Klientský interceptor: obnovit jednou při 401, pak zopakovat.
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));   // zopakovat
  }
  return res;
}
```

## Rotace refresh tokenů

Osvědčeným postupem je **rotace**: každé volání obnovení vrátí *nový* refresh token a zneplatní ten starý. Pokud je znovu předložen starý (již použitý) refresh token, signalizuje to krádež — server odvolá celou rodinu tokenů a vynutí opětovné přihlášení. To omezuje škody z odcizeného refresh tokenu.

## Ukládání

- **Refresh token** → cookie `httpOnly`, `Secure`, `SameSite`, aby ho JavaScript (a tedy XSS) nemohl přečíst.
- **Access token** → držený v paměti na klientovi; krátká životnost omezuje vystavení.
- Pokud se tomu můžete vyhnout, nikdy nedávejte ani jeden do `localStorage` — je čitelný jakýmkoli vloženým skriptem.

## Proč je to důležité

Tento průběh je páteří správy relací v moderních SPA, mobilních aplikacích a API, takže tazatelé očekávají, že ho vystopujete od začátku do konce: vydat oba při přihlášení, autorizovat pomocí access tokenu, transparentně obnovit při vypršení a kvůli bezpečnosti rotovat + odvolávat. Správně zvládnout detaily — bezstavové ověření, obnovení pouze na token endpointu, rotaci s detekcí opětovného použití a ukládání do `httpOnly` — je rozdíl mezi hladkou, bezpečnou relací a takovou, kde jediný odcizený token znamená dlouhodobé převzetí účtu.

Průběh

Rotace refresh tokenů

Ukládání

Proč je to důležité

Související otázky