Come funziona un JSON Web Token (JWT)?

Question

IT Interview Practice · Accepted Answer

Un **JSON Web Token (JWT)** è un token compatto, URL-safe e autocontenuto che trasporta claim su un utente. Il server lo firma una volta; in seguito può **verificarlo** a ogni richiesta senza un accesso al database — è ciò che rende *stateless* l'autenticazione basata su JWT.

## Struttura: tre parti base64url

Un JWT è `header.payload.signature`, tre segmenti codificati in base64url uniti da punti:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (claims)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** — l'algoritmo di firma, es. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — i **claim**: quelli standard come `sub` (subject/user id), `exp` (scadenza), `iat` (issued-at), `iss` (issuer), più eventuali campi personalizzati (`role`, `email`).
- **Signature** — calcolata su header e payload con un secret o una private key.

> Il payload è **codificato, non cifrato**. Chiunque può fare il base64-decode e leggerlo, quindi non mettere mai password o secret in un JWT.

## Come funzionano firma e verifica

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256** (simmetrico): lo stesso secret firma e verifica. Semplice, ma ogni verificatore deve possedere il secret.
- **RS256** (asimmetrico): una **private key** firma, una **public key** verifica. L'auth server tiene la private key; gli altri servizi verificano con la public key e non possono mai coniare token.

A ogni richiesta il server ricalcola la signature sull'header+payload ricevuti e la confronta. Se coincidono e `exp` è nel futuro, il token è considerato affidabile — nessun session store necessario.

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // solleva un'eccezione se manomesso o scaduto
  // claims.sub === "123"
} catch (e) {
  // rifiuta: non valido o scaduto
}
```

## La parte difficile: la revoca (revocation)

Poiché la verifica è stateless, **non puoi** invalidare un token prima della sua scadenza semplicemente "cancellandolo" lato server. Mitigazioni comuni:

- Mantieni gli access token **di breve durata** (5–15 min) e abbinali a un **refresh token** di durata più lunga.
- Mantieni una piccola **denylist** degli id dei token revocati (`jti`) per logout/compromissione — questo reintroduce un po' di stato.
- Ruota le chiavi di firma.

## Compromessi di archiviazione

| Archiviazione | Pro | Contro |
|---|---|---|
| Cookie `httpOnly` | Non leggibile da JS (più sicuro rispetto a XSS) | Richiede protezione CSRF |
| `localStorage` | Semplice, niente CSRF | Esposto a XSS |

## Perché è importante

I JWT alimentano l'autenticazione stateless tra API, microservizi e SPA — un servizio può fidarsi di una richiesta verificando solo una signature, senza un session store condiviso. Ma proprio quella statelessness è la classica trappola dei colloqui: i token non si revocano facilmente, il payload è leggibile e la confusione su `alg` o un controllo di scadenza mancante sono vulnerabilità reali. Sapere esattamente cosa protegge la signature, e cosa no, è essenziale per usare i JWT in sicurezza.

Archiviazione	Pro	Contro
Cookie `httpOnly`	Non leggibile da JS (più sicuro rispetto a XSS)	Richiede protezione CSRF
`localStorage`	Semplice, niente CSRF	Esposto a XSS

Struttura: tre parti base64url

Come funzionano firma e verifica

La parte difficile: la revoca (revocation)

Compromessi di archiviazione

Perché è importante

Domande correlate