Perché servono sia un access token sia un refresh token?

Question

IT Interview Practice · Accepted Answer

I due token esistono per risolvere un conflitto diretto: un access token deve essere **inviato a ogni richiesta** (quindi è molto esposto), eppure vuoi anche sessioni che **durino a lungo** senza costringere a login frequenti. Non puoi avere entrambe le cose in sicurezza in un solo token — quindi dividi il compito.

## I due ruoli

- **Access token** — di breve durata (tipicamente 5–15 minuti), inviato nell'header `Authorization` a ogni chiamata API. Poiché è trasmesso costantemente, una fuga è probabile; tenerlo breve significa che uno rubato scade quasi immediatamente.
- **Refresh token** — di lunga durata (giorni/settimane), inviato **solo** al token endpoint dell'auth server per ottenere nuovi access token. Viaggia raramente, può essere memorizzato in modo più sicuro e può essere revocato lato server.

```
Login ──▶ access (15m) + refresh (30d)
Ogni chiamata API ──▶ invia access
Access scaduto ──▶ invia refresh ──▶ nuovo access (+ refresh ruotato)
```

## Perché non un solo token?

| | Un access token a lunga durata | Access + refresh |
|---|---|---|
| Esposizione | Inviato a ogni richiesta, vive a lungo → grande finestra di furto | Access di breve durata; refresh inviato raramente |
| Revoca | Difficile (un JWT stateless non può essere ritirato) | Revoca il refresh token; l'access muore entro minuti |
| UX | Re-login frequente se breve | Resta loggato senza reinserire le credenziali |
| Raggio d'azione della fuga | Ampio | Piccolo (l'access scade in fretta) |

- **Un access token breve, senza refresh** → sicuro, ma l'utente viene disconnesso ogni pochi minuti. UX pessima.
- **Un access token lungo** → ottima UX, ma un token trapelato è valido a lungo e non può essere revocato facilmente.
- **Access + refresh** → finestra di esposizione breve *e* sessioni lunghe. Il refresh token è l'unico segreto a lunga durata e vive in un solo posto sicuro.

## Cosa abilita la separazione

- **Revoca nonostante gli access token stateless.** Non puoi invalidare un JWT access token prima che scada, ma *puoi* eliminare/negare il refresh token, così la sessione termina al refresh successivo (entro minuti).
- **Rotazione del refresh token** — emetti un nuovo refresh token a ogni uso e rileva il riutilizzo di uno vecchio (segno di furto), poi revoca l'intera catena.
- **Esposizione minima** — il segreto a lunga durata (refresh) viene inviato a esattamente un endpoint, idealmente memorizzato in un cookie `httpOnly`, fuori dalla portata dell'XSS.

## Perché è importante

Questo è il design di autenticazione moderno standard, e gli intervistatori lo chiedono per vedere se capisci il *perché*, non solo il *come*. L'intuizione chiave è il compromesso: statelessness ed esposizione breve (access) contro sessioni lunghe e revocabilità (refresh). Sbagliarlo — un access token a lunga durata, senza rotazione, refresh memorizzato in `localStorage` — trasforma un singolo token trapelato in una compromissione dell'account a lunga durata. Nominare la separazione e cosa ti offre ciascun token è ciò che ci si aspetta sappia un ingegnere attento alla sicurezza.

	Un access token a lunga durata	Access + refresh
Esposizione	Inviato a ogni richiesta, vive a lungo → grande finestra di furto	Access di breve durata; refresh inviato raramente
Revoca	Difficile (un JWT stateless non può essere ritirato)	Revoca il refresh token; l'access muore entro minuti
UX	Re-login frequente se breve	Resta loggato senza reinserire le credenziali
Raggio d'azione della fuga	Ampio	Piccolo (l'access scade in fretta)

I due ruoli

Perché non un solo token?

Cosa abilita la separazione

Perché è importante

Domande correlate