Miért van szükséged access tokenre és refresh tokenre is?

Question

IT Interview Practice · Accepted Answer

A két token egy közvetlen konfliktus feloldására létezik: egy access tokent **minden kérésnél el kell küldeni** (így sokat van kitéve), miközben olyan sessionöket is szeretnél, amelyek **sokáig tartanak** anélkül, hogy gyakori bejelentkezésre kényszerítenének. Egyetlen tokenben nem lehet mindkettő biztonságosan — ezért szétosztod a feladatot.

## A két szerep

- **Access token** — rövid életű (jellemzően 5–15 perc), az `Authorization` headerben elküldve minden API-hívásnál. Mivel folyamatosan továbbítódik, a szivárgás valószínű; ha rövid, egy ellopott szinte azonnal lejár.
- **Refresh token** — hosszú életű (napok/hetek), **csak** az auth szerver token endpointjára küldve, hogy új access tokeneket szerezz. Ritkán utazik, biztonságosabban tárolható, és szerveroldalon visszavonható.

```
Login ──▶ access (15m) + refresh (30d)
Minden API-hívás ──▶ access küldése
Access lejárt ──▶ refresh küldése ──▶ új access (+ rotált refresh)
```

## Miért ne csak egy token?

| | Egy hosszú életű access token | Access + refresh |
|---|---|---|
| Kitettség | Minden kérésnél elküldve, sokáig él → nagy lopási ablak | Access rövid életű; refresh ritkán küldve |
| Visszavonás | Nehéz (a stateless JWT nem vonható vissza) | Vond vissza a refresh tokent; az access percek alatt megszűnik |
| UX | Gyakori újra-bejelentkezés, ha rövid | Bejelentkezve marad hitelesítő adatok újbóli megadása nélkül |
| A szivárgás hatósugara | Nagy | Kicsi (az access gyorsan lejár) |

- **Egy rövid access token, refresh nélkül** → biztonságos, de a felhasználó pár percenként kijelentkezik. Szörnyű UX.
- **Egy hosszú access token** → remek UX, de egy kiszivárgott token sokáig érvényes, és nem vonható vissza könnyen.
- **Access + refresh** → rövid kitettségi ablak *és* hosszú sessionök. A refresh token az egyetlen hosszú életű titok, és egyetlen biztonságos helyen található.

## Mit tesz lehetővé a szétválasztás

- **Visszavonás a stateless access tokenek ellenére.** Egy JWT access tokent nem tudsz érvényteleníteni a lejárta előtt, de a refresh tokent *törölheted/megtagadhatod*, így a session a következő frissítéskor (perceken belül) véget ér.
- **Refresh token rotáció** — adj ki új refresh tokent minden használatkor, és észleld egy régi újbóli felhasználását (a lopás jele), majd vond vissza a teljes láncot.
- **Minimális kitettség** — a hosszú életű titkot (refresh) pontosan egy endpointra küldöd, ideális esetben egy `httpOnly` cookie-ban tárolva, az XSS hatókörén kívül.

## Miért fontos

Ez a modern hitelesítés standard megközelítése, és az interjúztatók azért kérdezik, hogy lássák, érted-e a *miértet*, nem csak a *hogyant*. A kulcsfontosságú felismerés a kompromisszum: a statelessség és a rövid kitettség (access) szemben a hosszú sessionökkel és a visszavonhatósággal (refresh). Ha elrontod — hosszú életű access token, rotáció nélkül, `localStorage`-ban tárolt refresh — egyetlen kiszivárgott tokent hosszú életű fiókfeltöréssé változtatsz. A szétválasztás megnevezése és annak, hogy melyik token mit ad, éppen az, amit egy biztonságtudatos mérnöktől elvárnak.

	Egy hosszú életű access token	Access + refresh
Kitettség	Minden kérésnél elküldve, sokáig él → nagy lopási ablak	Access rövid életű; refresh ritkán küldve
Visszavonás	Nehéz (a stateless JWT nem vonható vissza)	Vond vissza a refresh tokent; az access percek alatt megszűnik
UX	Gyakori újra-bejelentkezés, ha rövid	Bejelentkezve marad hitelesítő adatok újbóli megadása nélkül
A szivárgás hatósugara	Nagy	Kicsi (az access gyorsan lejár)

A két szerep

Miért ne csak egy token?

Mit tesz lehetővé a szétválasztás

Miért fontos

Kapcsolódó kérdések