Cum funcționează împreună token-urile de acces și token-urile de reîmprospătare?

Question

IT Interview Practice · Accepted Answer

Cele două token-uri urmează un ciclu de viață simplu: un **token de acces cu durată scurtă** autorizează fiecare apel API, iar un **token de reîmprospătare cu durată lungă** creează în tăcere token-uri de acces noi când acestea expiră — astfel utilizatorul rămâne autentificat fără a reintroduce credențialele.

## Fluxul

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. apel API: Authorization: Bearer <access>
     ▼
┌────────────┐  verifică semnătura + exp   (fără căutare în DB)
│ Resource   │ ──── 200 OK ────▶ (access încă valid)
│ API        │ ──── 401 ───────▶ (access expirat)
└────────────┘
     │  3. la 401: POST /token { refresh }
     ▼
┌────────────┐  verifică + rotește
│ Auth server│ ──── access nou (+ refresh nou) ────▶ reia apelul
└────────────┘
```

1. **Login** — utilizatorul se autentifică o dată; serverul returnează un **token de acces** (TTL scurt) și un **token de reîmprospătare** (TTL lung).
2. **Accesarea API-urilor** — clientul trimite token-ul de acces în `Authorization: Bearer …` la fiecare cerere. API-ul îl verifică stateless (semnătură + `exp`) și răspunde — nu e nevoie de un depozit de sesiuni.
3. **Reîmprospătare la expirare** — când API-ul returnează `401` (sau clientul vede că `exp` este aproape), clientul face POST cu **token-ul de reîmprospătare** către endpoint-ul `/token` al serverului de autentificare și primește un token de acces proaspăt, apoi reia cererea originală. Utilizatorul nu observă nimic.
4. **Logout / revocare** — serverul șterge sau pune token-ul de reîmprospătare pe lista de refuz; următoarea reîmprospătare eșuează și sesiunea se termină (token-ul de acces curent tot moare singur în câteva minute).

```js
// Interceptorul clientului: reîmprospătează o dată la 401, apoi reia.
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));   // reia
  }
  return res;
}
```

## Rotația token-ului de reîmprospătare

Cea mai bună practică este **rotația**: fiecare apel de reîmprospătare returnează un token de reîmprospătare *nou* și îl invalidează pe cel vechi. Dacă un token de reîmprospătare vechi (deja folosit) este prezentat din nou, asta semnalează furt — serverul revocă întreaga familie de token-uri și forțează reautentificarea. Acest lucru limitează dauna unui token de reîmprospătare furat.

## Stocare

- **Token de reîmprospătare** → cookie `httpOnly`, `Secure`, `SameSite` astfel încât JavaScript (și deci XSS) să nu-l poată citi.
- **Token de acces** → păstrat în memorie pe client; durata scurtă limitează expunerea.
- Nu pune niciunul în `localStorage` dacă poți evita — este citibil de orice script injectat.

## De ce contează

Acest flux este coloana vertebrală a gestionării sesiunilor în SPA-uri, aplicații mobile și API-uri moderne, așa că intervievatorii se așteaptă să-l urmărești cap-coadă: emite ambele la login, autorizează cu token-ul de acces, reîmprospătează transparent la expirare și rotește + revocă pentru siguranță. A face corect detaliile — verificare stateless, reîmprospătare doar la endpoint-ul de token, rotație cu detectarea reutilizării și stocare `httpOnly` — este diferența dintre o sesiune fluidă și sigură și una în care un singur token furat înseamnă o preluare de cont de lungă durată.

Fluxul

Rotația token-ului de reîmprospătare

Stocare

De ce contează

Întrebări conexe