Jak token dostępu i token odświeżający współpracują ze sobą?

Question

IT Interview Practice · Accepted Answer

Oba tokeny mają prosty cykl życia: **krótko żyjący token dostępu** autoryzuje każde wywołanie API, a **długo żyjący token odświeżający** po cichu wybija nowe tokeny dostępu, gdy te wygasają — dzięki czemu użytkownik pozostaje zalogowany bez ponownego wpisywania danych.

## Przepływ

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. wywołanie API: Authorization: Bearer <access>
     ▼
┌────────────┐  weryfikacja podpisu + exp   (bez zapytania do DB)
│ Resource   │ ──── 200 OK ────▶ (access wciąż ważny)
│ API        │ ──── 401 ───────▶ (access wygasł)
└────────────┘
     │  3. przy 401: POST /token { refresh }
     ▼
┌────────────┐  weryfikacja + rotacja
│ Auth server│ ──── nowy access (+ nowy refresh) ────▶ ponów wywołanie
└────────────┘
```

1. **Login** — użytkownik uwierzytelnia się raz; serwer zwraca **token dostępu** (krótki TTL) i **token odświeżający** (długi TTL).
2. **Dostęp do API** — klient wysyła token dostępu w `Authorization: Bearer …` przy każdym żądaniu. API weryfikuje go bezstanowo (podpis + `exp`) i odpowiada — magazyn sesji nie jest potrzebny.
3. **Odświeżenie przy wygaśnięciu** — gdy API zwraca `401` (lub klient widzi, że `exp` jest bliskie), klient wysyła **token odświeżający** metodą POST na punkt `/token` serwera uwierzytelniania i otrzymuje świeży token dostępu, a następnie ponawia oryginalne żądanie. Użytkownik niczego nie zauważa.
4. **Wylogowanie / unieważnienie** — serwer usuwa lub umieszcza token odświeżający na liście odmów; następne odświeżenie zawodzi i sesja się kończy (bieżący token dostępu i tak sam ginie w ciągu minut).

```js
// Interceptor klienta: odśwież raz przy 401, potem ponów.
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));   // ponów
  }
  return res;
}
```

## Rotacja tokenów odświeżających

Najlepszą praktyką jest **rotacja**: każde wywołanie odświeżenia zwraca *nowy* token odświeżający i unieważnia stary. Jeśli stary (już użyty) token odświeżający zostanie ponownie przedstawiony, sygnalizuje to kradzież — serwer unieważnia całą rodzinę tokenów i wymusza ponowne logowanie. Ogranicza to szkody ze skradzionego tokena odświeżającego.

## Przechowywanie

- **Token odświeżający** → ciasteczko `httpOnly`, `Secure`, `SameSite`, aby JavaScript (a więc XSS) nie mógł go odczytać.
- **Token dostępu** → przechowywany w pamięci po stronie klienta; krótki czas życia ogranicza narażenie.
- Nigdy nie umieszczaj żadnego z nich w `localStorage`, jeśli możesz tego uniknąć — jest odczytywalny przez dowolny wstrzyknięty skrypt.

## Dlaczego to ważne

Ten przepływ to kręgosłup zarządzania sesją w nowoczesnych SPA, aplikacjach mobilnych i API, więc rekruterzy oczekują, że prześledzisz go od początku do końca: wydaj oba przy logowaniu, autoryzuj tokenem dostępu, przejrzyście odświeżaj przy wygaśnięciu oraz rotuj + unieważniaj dla bezpieczeństwa. Poprawne zrobienie szczegółów — bezstanowa weryfikacja, odświeżanie tylko na punkcie tokenów, rotacja z wykrywaniem ponownego użycia i przechowywanie `httpOnly` — to różnica między płynną, bezpieczną sesją a taką, w której pojedynczy skradziony token oznacza długotrwałe przejęcie konta.

Przepływ

Rotacja tokenów odświeżających

Przechowywanie

Dlaczego to ważne

Powiązane pytania