JWT
2 tools
Fondamentali della sicurezza Web
La sicurezza Web è la pratica di proteggere le applicazioni Web e le API da accessi non autorizzati, violazioni dei dati e attacchi.
I JSON Web Token (JWT) sono il meccanismo di autenticazione stateless dominante nello sviluppo Web moderno.
JSON Web Tokens (JWT)
Un JWT è un modo compatto e sicuro per URL di rappresentare claim tra due parti. È composto da tre parti codificate in Base64url separate da punti.
Le tre parti di un JWT
Contiene metadati sul token: l'algoritmo di firma (alg) e il tipo di token (typ).
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9{
"alg": "HS256",
"typ": "JWT"
}Contiene i claim: dichiarazioni sull'utente. I dati del payload NON sono crittografati, solo firmati.
eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcxNzIwMDAwMH0{
"sub": "user_123",
"role": "admin",
"exp": 1717200000
}Una firma crittografica sull'intestazione e il payload codificati. La verifica garantisce che il token non sia stato manomesso.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cHMACSHA256( base64url(header) + "." + base64url(payload), secret )
Claim JWT standard
La specifica JWT definisce nomi di claim standard per garantire l'interoperabilità:
| Claim | Nome | Descrizione |
|---|---|---|
| iss | Issuer | Identifica il principal che ha emesso il token |
| sub | Subject | Identifica il principal che è il soggetto del token (es. ID utente) |
| aud | Audience | Identifica i destinatari per cui il token è destinato |
| exp | Expiration | Timestamp Unix dopo il quale il token non deve essere accettato |
| nbf | Not Before | Timestamp Unix prima del quale il token non deve essere accettato |
| iat | Issued At | Timestamp Unix in cui il token è stato emesso |
| jti | JWT ID | Identificatore univoco del token, usato per prevenire attacchi di replay |
Algoritmi di firma
L'algoritmo di firma è dichiarato nell'intestazione JWT. La scelta corretta è fondamentale per la sicurezza:
HS256 / HS384 / HS512Simmetrico (HMAC)Usa una chiave segreta condivisa per la firma e la verifica.
RS256 / RS384 / RS512Asimmetrico (RSA)Usa una chiave privata per firmare e una pubblica per verificare. La chiave privata non lascia mai il server di autenticazione.
ES256 / ES384 / ES512Asimmetrico (ECDSA)Come RSA ma con chiavi più piccole e firma più veloce.
"alg": "none"Non firmato — PERICOLOSONessuna firma. Un token con alg:none non ha garanzie di integrità.
Flussi di autenticazione
- 1.L'utente invia nome utente e password all'endpoint di login
- 2.Il server valida le credenziali contro il database utenti
- 3.Il server firma un JWT con i claim dell'utente e la scadenza
- 4.Il client memorizza il JWT (localStorage, cookie o memoria)
- 5.Il client invia il JWT nell'intestazione Authorization: Bearer per le richieste successive
- 1.Il client reindirizza l'utente al server di autorizzazione con la sfida del codice
- 2.L'utente si autentica e autorizza l'applicazione client
- 3.Il server di autenticazione reindirizza con un codice di autorizzazione monouso
- 4.Il client scambia codice + verificatore per token di accesso e aggiornamento
- 5.Il client usa il token di accesso per le chiamate API; il token di aggiornamento per il rinnovo
Vulnerabilità JWT comuni
I JWT sono sicuri quando implementati correttamente. Questi sono gli errori di implementazione più comuni:
Alcune librerie accettano token con alg:none. Un attaccante può modificare il payload e impostare alg su none per falsificare qualsiasi JWT.
Se una libreria deve verificare RS256 ma accetta HS256, un attaccante può firmare un token usando la chiave pubblica come segreto HMAC.
Un JWT senza claim exp permette l'uso indefinito dei token. Imposta sempre brevi tempi di scadenza.
I payload JWT sono codificati in Base64, non crittografati. Non memorizzare mai password o altri segreti nei claim JWT.
I JWT firmati con HMAC con segreti brevi o prevedibili possono essere violati offline con forza bruta.
Accettare JWT senza verificare la firma si fida completamente del payload. Verifica sempre la firma prima di fidarti dei claim.
Domande frequenti
I JWT standard (JWS) sono firmati ma NON crittografati. Il payload è codificato in Base64url, facilmente reversibile.
I token di accesso dovrebbero essere di breve durata: da 5 a 60 minuti è tipico. Usa token di aggiornamento per ottenere nuovi token di accesso.
I cookie HttpOnly sono l'opzione più sicura — inaccessibili a JavaScript, prevenendo il furto tramite XSS.
Non senza stato lato server. Soluzioni: brevi tempi di scadenza, una lista di blocco dei token (Redis).
I cookie di sessione memorizzano un ID di sessione casuale; il server cerca i dati di sessione. I JWT sono autonomi — il server valida la firma senza query al database.
Il minimo: sub (ID utente), exp (scadenza) e iat (emesso il). Mantieni i payload piccoli.
RS256 (asimmetrico) è migliore per la maggior parte dei sistemi di produzione perché solo il server di autenticazione ha bisogno della chiave privata.
PKCE è un'estensione del flusso di codice di autorizzazione OAuth2 che previene gli attacchi di intercettazione del codice. È obbligatorio per i client pubblici (SPA, app mobile).