Hogyan működik együtt az access token és a refresh token?

Question

IT Interview Practice · Accepted Answer

A két token egy egyszerű életciklust követ: egy **rövid életű access token** engedélyezi minden API-hívást, és egy **hosszú életű refresh token** csendben új access tokeneket készít, amikor azok lejárnak — így a felhasználó bejelentkezve marad anélkül, hogy újra megadná a hitelesítő adatait.

## A folyamat

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API-hívás: Authorization: Bearer <access>
     ▼
┌────────────┐  aláírás + exp ellenőrzése   (nincs DB-lekérdezés)
│ Resource   │ ──── 200 OK ────▶ (access még érvényes)
│ API        │ ──── 401 ───────▶ (access lejárt)
└────────────┘
     │  3. 401 esetén: POST /token { refresh }
     ▼
┌────────────┐  ellenőrzés + rotáció
│ Auth server│ ──── új access (+ új refresh) ────▶ hívás újrapróbálása
└────────────┘
```

1. **Login** — a felhasználó egyszer hitelesít; a szerver visszaad egy **access tokent** (rövid TTL) és egy **refresh tokent** (hosszú TTL).
2. **API-k elérése** — a kliens minden kérésnél elküldi az access tokent az `Authorization: Bearer …`-ben. Az API stateless módon ellenőrzi (aláírás + `exp`), és válaszol — nincs szükség session tárolóra.
3. **Frissítés lejáratkor** — amikor az API `401`-et ad vissza (vagy a kliens látja, hogy az `exp` közel van), a kliens POST-olja a **refresh tokent** az auth szerver `/token` endpointjára, és friss access tokent kap, majd újrapróbálja az eredeti kérést. A felhasználó semmit sem vesz észre.
4. **Kijelentkezés / visszavonás** — a szerver törli vagy tiltólistára teszi a refresh tokent; a következő frissítés sikertelen, és a session véget ér (a jelenlegi access token még magától elhal perceken belül).

```js
// Kliensoldali interceptor: egyszeri frissítés 401 esetén, majd újrapróbálás.
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));   // újrapróbálás
  }
  return res;
}
```

## Refresh token rotáció

A legjobb gyakorlat a **rotáció**: minden frissítési hívás egy *új* refresh tokent ad vissza, és érvényteleníti a régit. Ha egy régi (már használt) refresh tokent újra bemutatnak, az lopásra utal — a szerver visszavonja a teljes token-családot, és újra-bejelentkezésre kényszerít. Ez korlátozza egy ellopott refresh token kárát.

## Tárolás

- **Refresh token** → `httpOnly`, `Secure`, `SameSite` cookie, hogy a JavaScript (és így az XSS) ne tudja olvasni.
- **Access token** → a kliensen a memóriában tartva; a rövid élettartam korlátozza a kitettséget.
- Egyiket se tedd `localStorage`-ba, ha elkerülheted — bármely injektált szkript olvashatja.

## Miért fontos

Ez a folyamat a session-kezelés gerince a modern SPA-kban, mobilalkalmazásokban és API-kban, ezért az interjúztatók elvárják, hogy végigkövesd elejétől a végéig: mindkettő kiadása bejelentkezéskor, engedélyezés az access tokennel, átlátszó frissítés lejáratkor, valamint rotáció + visszavonás a biztonságért. A részletek helyes eltalálása — stateless ellenőrzés, frissítés csak a token endpointon, rotáció újrafelhasználás-észleléssel, és `httpOnly` tárolás — a különbség egy zökkenőmentes, biztonságos session és egy olyan között, ahol egyetlen ellopott token hosszú életű fiókátvételt jelent.

A folyamat

Refresh token rotáció

Tárolás

Miért fontos

Kapcsolódó kérdések