Glossary
JWT
JSON Web Token
By Buğra SözeriPublished Updated
JWT (JSON Web Token, pronunciato “jot”) è un formato di token definito in RFC 7519 per trasmettere claim firmate tra le parti. Un JWT è tre segmenti codificati in base64url separati da punti: intestazione.payload.firma.
L’intestazione dichiara l’algoritmo di firma (HS256, RS256, ES256, ecc.). Il payload è un oggetto JSON di claim — sub (soggetto), iss (emettitore), exp (scadenza), iat (emesso a), più qualsiasi campo specifico dell’applicazione. La firma è calcolata su base64url(intestazione) + "." + base64url(payload) usando l’algoritmo e la chiave dichiarati nell’intestazione.
I JWT vengono usati per l’autenticazione stateless (il server non ha bisogno di memorizzare sessioni; verifica la firma su ogni richiesta), l’autorizzazione tra servizi (token bearer OAuth 2.0, token ID OpenID Connect) e URL a breve durata che codificano claim di accesso.
Insidie comuni: fidarsi di alg: none, accettare token con chiave simmetrica dove era attesa quella asimmetrica, non validare exp. Il decodificatore JWT ispeziona il contenuto di un token — non verifica la firma, perché la verifica richiede la chiave dell’emettitore.
Esempio pratico
Decodifica il JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTcxNjQwMDAwMCwiZXhwIjoxNzE2NDg2NDAwfQ.signature. Intestazione: {"alg":"HS256","typ":"JWT"}. Payload: {"sub":"12345","name":"Alice","iat":1716400000,"exp":1716486400}. Il token è stato emesso al tempo Unix 1716400000 (un momento del maggio 2024) e scade 86.400 secondi dopo — esattamente 24 ore. Un verificatore che riceve questo token deve: (1) ricalcolare HMAC-SHA256 di intestazione.payload con il segreto condiviso e verificare che corrisponda alla firma; (2) verificare exp rispetto all’ora corrente e rifiutare se scaduto; (3) verificare opzionalmente che iss (emettitore) e aud (destinatario) corrispondano ai valori attesi. Chiunque — incluso il browser dell’utente, qualsiasi proxy intermedio o un attaccante che ruba il token — può decodificare in base64 il payload e vedere il nome e l’ID utente di Alice. Il token è firmato, non cifrato.
Quando e perché è importante
JWT è importante ogni volta che l’autenticazione stateless è la scelta di design — tipico per le SPA che comunicano con API REST, le app mobili con servizi backend, le federazioni OAuth 2.0 / OpenID Connect e l’autorizzazione tra microservizi. Gli errori da evitare: (1) inserire dati personali o sensibili nel payload (è leggibile da chiunque abbia il token); (2) usare tempi di scadenza lunghi senza una strategia di revoca (i token con durata 24h+ sono pericolosi se rubati); (3) accettare alg: none o lasciare che il token scelga l’algoritmo; (4) memorizzare i JWT in localStorage dove XSS può rubarli — preferisci i cookie httpOnly con SameSite=Lax; (5) non validare aud, accettando token emessi per servizi fratelli. Il pattern che funziona bene: token di accesso di 5-15 minuti + token di aggiornamento revocabili a lunga durata + sessione opaca lato server per le operazioni genuinamente sensibili. Riferimento: RFC 8725 — JSON Web Token Best Current Practices.
Perché i JWT non sono cifrati per default: un JWT standard è firmato ma non riservato — chiunque abbia il token può decodificare in base64 il payload e leggere ogni claim, inclusa l’email dell’utente, i ruoli e qualsiasi dato specifico dell’applicazione che l’emettitore ha scelto di incorporare. Questo coglie ripetutamente di sorpresa gli ingegneri: inserire dati personali o ID utente interni in un JWT assumendo che il token sia una scatola nera è una perdita di dati in attesa di accadere. Per la riservatezza, cifra il payload usando JWE (JSON Web Encryption, RFC 7516), che produce un token a cinque segmenti con cifratura adeguata insieme alla firma. La maggior parte dei sistemi in produzione tiene i dati personali fuori dal payload o usa token di sessione opachi con ricerche di stato lato server.
Token di aggiornamento, scadenza e il problema della revoca: la verifica stateless è la caratteristica principale di JWT e anche la sua principale responsabilità operativa — una volta emesso, un JWT non può essere revocato fino alla scadenza. La mitigazione standard sono i token di accesso a breve durata (5-15 minuti) abbinati a token di aggiornamento a lunga durata (giorni o mesi) che sono revocabili tramite una denylist lato server; il client scambia periodicamente il token di aggiornamento per un nuovo token di accesso. I JWT a lunga durata (24 ore e oltre) sono un anti-pattern per qualsiasi cosa sensibile — un token rubato è un lasciapassare gratuito fino alla scadenza. Il decodificatore JWT di Convertitive evidenzia la claim exp così puoi vedere rapidamente se un token ha una durata eccessiva. Riferimento: RFC 7519 — JSON Web Token.
Prova il calcolatore
Incolla un JWT per ispezionare intestazione, payload e firma senza eseguire nulla lato server.
Apri il decodificatore JWT →Frequently asked questions
- Che cos’è un JWT?
- Un JWT (JSON Web Token, pronunciato ‘jot’) è un formato di token compatto e URL-safe definito in RFC 7519. Codifica claim firmate come tre segmenti codificati in base64url — intestazione, payload, firma — separati da punti.
- Come si usa un JWT per l’autenticazione?
- Dopo il login, il server emette un JWT firmato contenente l’ID dell’utente e la scadenza. Il client lo invia nell’intestazione Authorization: Bearer nelle richieste successive; il server verifica la firma e si fida delle claim senza interrogare un session store.
- I JWT sono cifrati?
- No — un JWT standard è firmato, non cifrato. Chiunque detenga il token può decodificare in base64 il payload e leggere ogni claim. Per payload riservati usa JWE (JSON Web Encryption), o tieni i dati sensibili fuori dal token del tutto.
- Qual è l’errore di sicurezza JWT più comune?
- Usare tempi di scadenza lunghi (ore o giorni) senza una strategia di revoca. Un JWT rubato è valido fino alla scadenza; mitigalo con token di accesso a breve durata (5-15 minuti) abbinati a token di aggiornamento revocabili lato server.
Related
Published May 14, 2026 · Last reviewed May 31, 2026