JSON Web Token (JWT): Guida all'Autenticazione e Sicurezza

Cos'è JWT?

JWT (JSON Web Token) è un formato di token compatto e sicuro per URL, definito in RFC 7519, utilizzato per lo scambio sicuro di informazioni tra parti.

JWT è composto da tre parti: Header, Payload e Signature. Queste tre parti sono separate da punti (.): xxxxx.yyyyy.zzzzz

Fornisce autenticazione stateless. Invece di memorizzare i dati della sessione in un database, il server invia il token al client. Il client invia il token con ogni richiesta.

Casi d'uso: Autenticazione API, SSO (Single Sign-On), autenticazione tra microservizi, autorizzazione di app mobili.

Struttura JWT

Header: Contiene tipo di token (JWT) e algoritmo di firma (HS256, RS256, ES256). Codificato in Base64URL.

Payload: Contiene claims. Registered claims (iss, sub, aud, exp, nbf, iat, jti), public claims e private claims. Codificato in Base64URL.

Signature: Header e payload codificati in Base64URL sono uniti da un punto e firmati con una chiave segreta. HS256 usa HMAC-SHA256, RS256 usa RSA-SHA256.

Esempio: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Flusso di utilizzo JWT

1. L'utente invia una richiesta all'endpoint di login con nome utente e password.

2. Il server verifica le credenziali e crea un JWT. Il token viene restituito nel body della risposta o in un cookie.

3. Il client memorizza il token in localStorage o cookie httpOnly.

4. Nelle richieste successive, il client invia JWT come Bearer token nell'header Authorization: Authorization: Bearer <token>

5. Il server valida il token (verifica firma e scadenza). Se valido, elabora la richiesta; se non valido, restituisce 401 Unauthorized.

Rischi di sicurezza

Furto di token: Il token in localStorage può essere rubato tramite attacco XSS. Usa cookie httpOnly per ridurre il rischio XSS.

Durata del token: Access token di breve durata (15-30 min) + refresh token di lunga durata (7-30 giorni). Ruota il refresh token ad ogni uso.

Confusione di algoritmo: Algoritmo 'none' o cambio RS256→HS256. Imposta l'algoritmo come costante lato server, non prenderlo dal token.

Dati sensibili: Il payload JWT è codificato in Base64, non cifrato. Non mettere dati sensibili (password, carta di credito) nel payload.

Dimensione del token: JWT è più grande di un cookie di sessione. Inviato con ogni richiesta. Mantieni il payload minimo.

Best practices

Token di breve durata: Access token 15-30 minuti, refresh token 7-30 giorni. I token scaduti diventano automaticamente invalidi.

Cookie httpOnly + Secure + SameSite: Memorizza il token in un cookie httpOnly. JavaScript non può accedervi (protezione XSS). Secure (solo HTTPS). SameSite (protezione CSRF).

Rotazione del token: Il refresh token viene rinnovato ad ogni uso. Il vecchio refresh token diventa invalido. Limita l'accesso dell'attaccante in caso di furto di token.

Blacklist/revoca: Usa blacklist per revocare i token. Memorizza i token revocati in Redis. Usa per logout e incidenti di sicurezza.

Algoritmo: RS256 (asimmetrico) raccomandato per la produzione. Firma con chiave privata, verifica con chiave pubblica. HS256 (simmetrico) solo per un singolo servizio.

Validazione: Verifica firma, issuer (iss), audience (aud), scadenza (exp) ad ogni richiesta. Assicurati che tutti i controlli passino prima di fidarti del token.

JWT vs Autenticazione basata su sessione

JWT: Stateless, scaling orizzontale facile, ideale per microservizi, dimensione token grande, difficile da revocare.

Session: Stateful, richiede archiviazione lato server, necessita di sticky session o shared store per scaling orizzontale, dimensione token piccola, facile da revocare.

Criteri di selezione: Architettura microservizi → JWT. Applicazione monolitica → Session. App mobile → JWT. Alto requisito di sicurezza → Session + JWT ibrido.

Approccio ibrido: JWT di breve durata (access token) + session store (refresh token). Combina i vantaggi di entrambi.