Come funzionano insieme access token e refresh token?

Question

IT Interview Practice · Accepted Answer

I due token seguono un ciclo di vita semplice: un **access token di breve durata** autorizza ogni chiamata API, e un **refresh token di lunga durata** conia silenziosamente nuovi access token quando scadono — così l'utente resta loggato senza reinserire le credenziali.

## Il flusso

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. chiamata API: Authorization: Bearer <access>
     ▼
┌────────────┐  verifica firma + exp   (nessuna lookup DB)
│ Resource   │ ──── 200 OK ────▶ (access ancora valido)
│ API        │ ──── 401 ───────▶ (access scaduto)
└────────────┘
     │  3. su 401: POST /token { refresh }
     ▼
┌────────────┐  verifica + rotazione
│ Auth server│ ──── nuovo access (+ nuovo refresh) ────▶ riprova la chiamata
└────────────┘
```

1. **Login** — l'utente si autentica una volta; il server restituisce un **access token** (TTL breve) e un **refresh token** (TTL lungo).
2. **Accesso alle API** — il client invia l'access token in `Authorization: Bearer …` a ogni richiesta. L'API lo verifica in modo stateless (firma + `exp`) e risponde — nessun session store necessario.
3. **Refresh alla scadenza** — quando l'API restituisce `401` (o il client vede che `exp` è vicino), il client fa una POST del **refresh token** all'endpoint `/token` dell'auth server e ottiene un nuovo access token, poi riprova la richiesta originale. L'utente non nota nulla.
4. **Logout / revoca** — il server elimina o mette in denylist il refresh token; il refresh successivo fallisce e la sessione termina (l'access token corrente muore comunque da solo entro minuti).

```js
// Interceptor del client: refresh una volta su 401, poi riprova.
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));   // riprova
  }
  return res;
}
```

## Rotazione del refresh token

La best practice è la **rotazione**: ogni chiamata di refresh restituisce un *nuovo* refresh token e invalida quello vecchio. Se un vecchio refresh token (già usato) viene presentato di nuovo, questo segnala un furto — il server revoca l'intera famiglia di token e forza un nuovo login. Questo limita il danno di un refresh token rubato.

## Archiviazione

- **Refresh token** → cookie `httpOnly`, `Secure`, `SameSite` così che JavaScript (e quindi l'XSS) non possa leggerlo.
- **Access token** → tenuto in memoria sul client; la breve durata limita l'esposizione.
- Non mettere nessuno dei due in `localStorage` se puoi evitarlo — è leggibile da qualsiasi script iniettato.

## Perché è importante

Questo flusso è la spina dorsale della gestione delle sessioni in SPA, app mobile e API moderne, quindi gli intervistatori si aspettano che tu lo ripercorra dall'inizio alla fine: emettere entrambi al login, autorizzare con l'access token, fare refresh in modo trasparente alla scadenza, e ruotare + revocare per sicurezza. Azzeccare i dettagli — verifica stateless, refresh solo al token endpoint, rotazione con rilevamento del riutilizzo, e archiviazione `httpOnly` — è la differenza tra una sessione fluida e sicura e una in cui un singolo token rubato significa un takeover dell'account a lunga durata.

Il flusso

Rotazione del refresh token

Archiviazione

Perché è importante

Domande correlate