Kako dostopni žetoni in žetoni za osvežitev delujejo skupaj?

Question

IT Interview Practice · Accepted Answer

Žetona sledita preprostemu življenjskemu ciklu: **kratkoživ dostopni žeton** avtorizira vsak klic API, **dolgoživ žeton za osvežitev** pa ob poteku tiho kuje nove dostopne žetone — tako ostane uporabnik prijavljen brez ponovnega vnosa poverilnic.

## Potek

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. klic API: Authorization: Bearer <access>
     ▼
┌────────────┐  preveri podpis + exp   (brez poizvedbe v DB)
│ Resource   │ ──── 200 OK ────▶ (access še veljaven)
│ API        │ ──── 401 ───────▶ (access potekel)
└────────────┘
     │  3. ob 401: POST /token { refresh }
     ▼
┌────────────┐  preveri + zavrti
│ Auth server│ ──── nov access (+ nov refresh) ────▶ ponovi klic
└────────────┘
```

1. **Login** — uporabnik se avtenticira enkrat; strežnik vrne **dostopni žeton** (kratek TTL) in **žeton za osvežitev** (dolg TTL).
2. **Dostop do API-jev** — odjemalec pošlje dostopni žeton v `Authorization: Bearer …` ob vsaki zahtevi. API ga preveri brez stanja (podpis + `exp`) in odgovori — shramba sej ni potrebna.
3. **Osvežitev ob poteku** — ko API vrne `401` (ali odjemalec vidi, da je `exp` blizu), odjemalec s POST pošlje **žeton za osvežitev** na končno točko `/token` avtentikacijskega strežnika in dobi svež dostopni žeton, nato ponovi izvirno zahtevo. Uporabnik ne opazi ničesar.
4. **Odjava / preklic** — strežnik izbriše ali doda žeton za osvežitev na seznam zavrnitev; naslednja osvežitev spodleti in seja se konča (trenutni dostopni žeton kljub temu sam umre v nekaj minutah).

```js
// Prestreznik odjemalca: enkrat osveži ob 401, nato ponovi.
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));   // ponovi
  }
  return res;
}
```

## Rotacija žetona za osvežitev

Najboljša praksa je **rotacija**: vsak klic osvežitve vrne *nov* žeton za osvežitev in razveljavi starega. Če je star (že uporabljen) žeton za osvežitev znova predložen, to nakazuje krajo — strežnik prekliče celotno družino žetonov in prisili k ponovni prijavi. To omeji škodo ukradenega žetona za osvežitev.

## Shranjevanje

- **Žeton za osvežitev** → piškotek `httpOnly`, `Secure`, `SameSite`, da ga JavaScript (in s tem XSS) ne more prebrati.
- **Dostopni žeton** → hranjen v pomnilniku na odjemalcu; kratka življenjska doba omejuje izpostavljenost.
- Nikoli ne shranjuj nobenega v `localStorage`, če se lahko izogneš — bere ga lahko vsaka vbrizgana skripta.

## Zakaj je to pomembno

Ta potek je hrbtenica upravljanja sej v sodobnih SPA, mobilnih aplikacijah in API-jih, zato spraševalci pričakujejo, da ga izsledite od začetka do konca: izdaj oba ob prijavi, avtoriziraj z dostopnim žetonom, pregledno osveži ob poteku ter zavrti + prekliči zaradi varnosti. Pravilne podrobnosti — preverjanje brez stanja, osvežitev samo na žetonski končni točki, rotacija z zaznavanjem ponovne uporabe in shramba `httpOnly` — so razlika med gladko, varno sejo in tako, kjer en sam ukraden žeton pomeni dolgotrajno prevzemanje računa.

Potek

Rotacija žetona za osvežitev

Shranjevanje

Zakaj je to pomembno

Povezana vprašanja