Cos'è JWT - JSON Web Token? Definizione Completa e Guida Pratica
Un JWT (JSON Web Token) è un token compatto e autocontenuto che trasmette in modo sicuro informazioni tra due parti. Firmato digitalmente, permette al server di verificarne autenticità e integrità senza consultare un database. È lo standard per autenticare le richieste API nei sistemi moderni, incluso il widget chatbot di V Support.
Cos'è un JWT?
I JSON Web Token sono definiti nello standard RFC 7519 e sono diventati lo strumento predominante per l'autenticazione nelle API REST e nelle architetture a microservizi. La loro forza sta nell'essere autocontenuti: il token stesso porta con sé tutte le informazioni necessarie per identificare l'utente e verificare la validità della richiesta, senza che il server debba fare una ricerca in un database ad ogni richiesta.
Un JWT viene generato dal server dopo un'autenticazione riuscita (login) e inviato al client. Il client lo conserva (localStorage, cookie HttpOnly, memoria) e lo include in ogni richiesta successiva nell'header Authorization. Il server riceve il token, verifica la firma crittografica e legge i dati (claims) in esso contenuti, tutto senza I/O su database.
In V Support, i JWT autenticano le sessioni degli amministratori con Supabase Auth, autorizzano il widget chatbot a comunicare con il backend, e garantiscono l'isolamento multi-tenant: ogni token contiene l'identificativo del tenant e le policy RLS lo usano per filtrare i dati.
Struttura di un JWT
Le Tre Parti: Header . Payload . Signature
Un JWT è una stringa di tre blocchi separati da punti, ognuno codificato in Base64URL:
Parte 1: Header
Contiene il tipo di token ("JWT") e l'algoritmo crittografico usato per firmare:
"alg": "RS256",
"typ": "JWT"
}
Algoritmi comuni: HS256 (HMAC-SHA256, chiave simmetrica), RS256 (RSA, chiave asimmetrica), ES256 (ECDSA). RS256 e ES256 sono preferiti in produzione perché il server può verificare senza esporre la chiave privata.
Parte 2: Payload (i Claims)
Contiene le "claims", ovvero le informazioni sull'utente e sulla sessione. Ci sono claims standard (registered claims) e claims custom dell'applicazione:
"sub": "user_123", // Subject: ID utente
"email": "mario@esempio.it",
"role": "admin",
"tenant_id": "azienda_xyz",
"iat": 1708000000, // Issued At: quando emesso
"exp": 1708003600 // Expiry: scade tra 1 ora
}
Importante: il payload è solo codificato in Base64URL, NON cifrato. Chiunque con il token può leggerne il contenuto. Non includere mai dati sensibili (password, chiavi API, dati finanziari).
Parte 3: Signature
La firma garantisce che il token non sia stato manomesso. Viene calcolata firmando header + payload con la chiave segreta del server:
base64url(header) + "." + base64url(payload),
privateKey
)
Se qualcuno modifica anche un solo carattere del payload, la firma non coincide più e il token viene rifiutato. La verifica usa la chiave pubblica (RS256), che può essere condivisa senza compromettere la sicurezza.
JWT vs Sessione Tradizionale
| Aspetto | JWT | Sessione Tradizionale |
|---|---|---|
| Storage Server | Nessuno (stateless) | Database/Redis (stateful) |
| Verifica | Solo firma crittografica | Query al database |
| Scalabilità | Eccellente (niente stato condiviso) | Richiede sessione condivisa tra server |
| Revoca | Complessa (token valido fino a exp) | Immediata (elimina sessione dal DB) |
| Dimensione | Più grande (base64 claims) | Solo session_id (piccolo) |
| Ideale per | API, microservizi, sistemi distribuiti | Web app tradizionali, monoliti |
Sicurezza JWT: Best Practice
Scadenza Breve + Refresh Token
Gli access token JWT devono avere scadenza breve (15 minuti - 1 ora). Se un token viene intercettato, la finestra di vulnerabilità è limitata. Per mantenere la sessione utente attiva, usa un refresh token (scadenza lunga, es. 30 giorni) per ottenere nuovi access token senza richiedere il login. Supabase Auth gestisce questo ciclo automaticamente.
Storage Sicuro Lato Client
Il JWT non deve essere salvato in localStorage (vulnerabile a XSS). Meglio usare cookie HttpOnly + SameSite=Strict (inaccessibili a JavaScript, protetti da CSRF) oppure tenerlo solo in memoria (perso al refresh della pagina, ma massima sicurezza). La scelta dipende dal trade-off tra sicurezza e UX dell'applicazione.
Non Includere Dati Sensibili nel Payload
Il payload JWT è visibile a chiunque abbia il token, è solo codificato (Base64URL), non cifrato. Include solo dati necessari per l'autorizzazione (user_id, role, tenant_id) e mai dati sensibili (password, chiavi API, dati finanziari, PII). Per trasmettere dati cifrati usa JWE (JSON Web Encryption), non JWS (JWT standard).
Validazione Completa Server-Side
Il server deve sempre: verificare la firma con la chiave corretta, controllare che il token non sia scaduto (claim exp), verificare l'audience (aud) e l'issuer (iss) se configurati, controllare eventuali claim custom necessari (tenant_id, role). Mai fidarsi dei claims senza aver verificato la firma: sarebbe come leggere un documento senza controllare il timbro.
Domande Frequenti
Cos'è un JWT?
Un JWT (JSON Web Token) è un token firmato crittograficamente che contiene informazioni sull'identità e i permessi di un utente. Composto da tre parti (header, payload, signature) separate da punti, permette al server di verificare autenticità e integrità senza consultare un database. È lo standard per l'autenticazione nelle API REST e nei sistemi distribuiti moderni.
JWT è sicuro?
I JWT sono sicuri se implementati correttamente: algoritmo robusto (RS256 o ES256), scadenza breve (15-60 minuti), storage in cookie HttpOnly (non localStorage), payload senza dati sensibili, validazione completa server-side. Non sono adatti a tutti i casi d'uso: la revoca immediata è complessa, e per applicazioni con requisiti di logout istantaneo una sessione server-side tradizionale può essere più appropriata.
Differenza JWT vs sessione tradizionale?
La sessione tradizionale salva i dati utente sul server e invia al client solo un ID opaco. Il JWT è self-contained: i dati sono nel token stesso e il server non consulta database per ogni richiesta. I JWT sono ideali per API distribuite e microservizi (niente stato condiviso tra server), ma la revoca è più complessa. Le sessioni tradizionali permettono logout istantaneo ma richiedono storage condiviso in architetture multi-server.
Termini Correlati
Implementa JWT - JSON Web Token nella Tua Azienda
Scopri come V Support può aiutarti a sfruttare l'AI per il tuo customer service. Demo gratuita di 30 minuti.