--- title: "Cos’è il JSON Web Token e come funziona" url: https://www.conseolente.it/cose-il-json-web-token-come-funziona/ aggiornato: 2026-10-28 descrizione: "Scopri cos'è il JSON Web Token (JWT), come funziona, la struttura con header, payload e signature, e gli algoritmi di firma HMAC e RSA." topic: "API · · Cos’è il JSON Web Token e come funziona" --- # Cos’è il JSON Web Token e come funziona > Versione per assistenti AI. Pagina originale: [Cos’è il JSON Web Token e come funziona](https://www.conseolente.it/cose-il-json-web-token-come-funziona/?via=md) Il JSON Web Token (JWT) è uno standard aperto che racchiude informazioni in un oggetto JSON firmato digitalmente, usato per trasmettere dati di autenticazione tra un server e un client senza dover salvare una sessione sul server. La firma garantisce che il contenuto non sia stato alterato lungo il percorso. ## JSON Web Token in sintesi - **Standard di riferimento:** RFC 7519, pubblicata dall’IETF nel maggio 2015. - **Struttura:** tre parti separate da un punto, header, payload e signature, ciascuna codificata in Base64Url. - **Firma:** simmetrica con HMAC e una chiave condivisa, oppure asimmetrica con RSA o ECDSA e una coppia di chiavi. - **Trasporto:** l’header HTTP Authorization, con lo schema Bearer, nelle richieste alle risorse protette. - **Attenzione:** il payload è solo codificato, non cifrato, quindi leggibile da chiunque intercetti il token. - **Limite noto:** un JWT emesso resta valido fino alla scadenza, anche se l’account viene bloccato nel frattempo. ## Cos’è un JSON Web Token Un JWT è una stringa compatta che trasporta un insieme di affermazioni, le claims, firmate digitalmente e scambiate tra due sistemi che non si fidano a priori l’uno dell’altro. Lo standard è descritto nella RFC 7519, pubblicata dall’IETF nel maggio 2015, dopo una prima proposta circolata già nel 2010. Un modo semplice per capirlo è pensarlo come una busta sigillata con la ceralacca, non chiusa a chiave. Chi la riceve non può modificarne il contenuto senza rompere il sigillo, ma può leggerlo senza problemi, perché l’header e il payload sono solo codificati in Base64Url, non cifrati. La firma può essere calcolata con un segreto condiviso (HMAC) oppure con una coppia di chiavi pubblica e privata (RSA o ECDSA): la scelta tra i due approcci cambia chi può verificare il token e chi può crearlo, come si vede più avanti. Il JWT nasce per sostituire meccanismi di sessione più pesanti in contesti distribuiti, dove un’applicazione parla con più server o microservizi diversi. Le query attuali con quel contenuto trasportato dentro una richiesta HTTP arrivano quasi sempre nell’header [Hypertext Transfer Protocol (HTTP)](https://www.conseolente.it/hypertext-transfer-protocol-http-cose-come-funziona/), che è il canale su cui viaggia tutta la comunicazione tra client e server, token compreso. ## Perché JWT si pronuncia «jot» La RFC 7519 suggerisce esplicitamente di pronunciare JWT come la parola inglese “jot”, non lettera per lettera. L’indicazione è degli autori dello standard, Michael B. Jones, John Bradley e Nat Sakimura. Non è una regola che cambia nulla dal punto di vista tecnico, ma capita spesso che chi è alle prime armi con l’argomento dica “jei-dabliu-ti” lettera per lettera, ed è perfettamente comprensibile comunque. Da non confondere con il Java Web Toolkit, un framework per interfacce web scritto in Java, che condivide la sigla ma non ha nulla a che fare con l’autenticazione via token. ## Struttura di un JWT Un JWT è composto da tre parti separate da un punto: header.payload.signature. Ognuna delle tre parti è codificata separatamente in Base64Url e poi concatenata, ottenendo una stringa simile a eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.firma, dove si nota perché molti JWT iniziano con “eyJ”: è la codifica Base64Url della sequenza di caratteri {" con cui si apre quasi sempre il JSON dell’header. ### Header L’header contiene i metadati del token: il tipo, quasi sempre “JWT”, e l’algoritmo usato per firmarlo, per esempio HS256 o RS256. È un piccolo oggetto JSON, codificato in Base64Url per diventare la prima parte della stringa finale. ### Payload Il payload contiene le claims, cioè le informazioni effettive trasportate dal token. Esistono tre categorie: le claims registrate, come iss (chi ha emesso il token), sub (a chi si riferisce), exp (quando scade), iat (quando è stato emesso), aud (a chi è destinato), nbf (da quando è valido) e jti (un identificatore univoco del token); le claims pubbliche, definibili liberamente ma da registrare presso lo IANA JWT Claims Registry per evitare collisioni di nome; le claims private, create su misura tra le parti che si scambiano il token. ### Signature La firma si ottiene applicando l’algoritmo indicato nell’header all’header e al payload codificati, insieme a un segreto o a una chiave privata: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret). Chi riceve il token rifà lo stesso calcolo e confronta il risultato: se non coincide, il token è stato manomesso o il segreto usato non è quello giusto. ## Come funziona un JWT nel flusso di autenticazione Un JWT funziona in cinque passaggi, dal login alla validazione di ogni richiesta successiva, senza che il server debba interrogare un database a ogni controllo. 1. Il client invia username e password al server tramite una richiesta di login. 2. Il server verifica le credenziali e genera un JWT, firmandolo con una chiave nota solo a lui. 3. Il server restituisce il token al client, che lo conserva, in un cookie o nello storage del browser. 4. A ogni richiesta verso una risorsa protetta, il client invia il token nell’header Authorization, con la forma Authorization: Bearer . 5. Il server verifica la firma e la scadenza del token: se entrambe sono valide, autorizza l’azione senza consultare altre fonti. Questo è il motivo per cui si parla di autenticazione stateless: tutte le informazioni necessarie a riconoscere l’utente stanno dentro il token stesso. Vale finché il payload contiene davvero ciò che serve a quella verifica: se un’applicazione deve controllare permessi che cambiano spesso, il server torna comunque a interrogare un database, e lo stateless resta solo parziale. ## Algoritmi di firma: HMAC o RSA/ECDSA La scelta dell’algoritmo di firma dipende da chi deve poter verificare il token e da chi deve poterlo creare: con HMAC lo stesso segreto fa entrambe le cose, con RSA o ECDSA le due operazioni sono separate. | Caratteristica | HMAC (HS256) | RSA / ECDSA (RS256, ES256) | | --- | --- | --- | | Chiave usata | Un unico segreto condiviso | Coppia di chiavi pubblica e privata | | Chi può firmare | Chiunque conosca il segreto | Solo chi possiede la chiave privata | | Chi può verificare | Chiunque conosca lo stesso segreto | Chiunque abbia la chiave pubblica, senza poter firmare | | Quando conviene | Un solo sistema emette e verifica i token (es. backend monolitico) | Più sistemi devono verificare i token senza poterli emettere (es. architetture a microservizi) | Nel mio lavoro consiglio HMAC quando l’applicazione è un unico backend che emette e controlla i propri token: è più semplice da gestire e non richiede un’infrastruttura di chiavi. Se invece più servizi indipendenti devono solo verificare un token emesso altrove, senza doverlo mai generare, preferisco RSA o ECDSA, perché evita di distribuire il segreto a sistemi che non dovrebbero poterlo usare per firmare nulla. ## Vantaggi e svantaggi di un JWT Un JWT riduce il carico sul server perché non richiede di salvare sessioni, ma porta con sé limiti che vanno valutati prima di adottarlo, non dopo. Tra i vantaggi: il token è compatto e passa facilmente in un header HTTP, in un parametro URL o nel corpo di una richiesta POST; è autonomo, perché contiene già le informazioni necessarie a riconoscere l’utente; funziona bene tra domini diversi, cosa utile nelle API REST e nelle architetture a microservizi dove più sistemi devono fidarsi dello stesso token. Tra i limiti: più claims si aggiungono al payload, più il token cresce, e questo pesa su ogni singola richiesta HTTP. Alcuni server rifiutano header HTTP oltre gli 8 KB: non è un limite dello standard JWT, ma una condizione di configurazione del server che vale la pena controllare se il payload si allarga parecchio. Il limite più serio però è un altro: un JWT firmato resta valido fino alla sua scadenza naturale, e revocarlo prima richiede un meccanismo aggiuntivo, come una blacklist lato server, perché lo standard non ne prevede uno nativo. Infine il payload è leggibile da chiunque intercetti il token: non ci va mai una password o un dato sensibile, a meno di usare la cifratura JWE insieme alla firma JWS. ## Dove memorizzare il token lato client Dove salvare un JWT dipende dal rischio che si vuole ridurre: furto tramite script malevoli o complicazioni nella gestione delle richieste cross-dominio. ### Se il rischio principale è lo script malevolo (XSS): usa un cookie HttpOnly Un cookie marcato HttpOnly non è leggibile da JavaScript, nemmeno da uno script iniettato tramite una vulnerabilità del sito. Serve però impostare credentials: 'include' nelle chiamate verso API su un altro dominio, perché il browser invii il cookie automaticamente. ### Se serve semplicità nelle chiamate cross-dominio: usa localStorage, con cautela Salvare il token in localStorage o sessionStorage semplifica l’invio manuale nell’header Authorization verso domini diversi, ma espone il token a qualunque script giri sulla pagina, compresi quelli di terze parti caricati per errore. La mia posizione è sconsigliarlo su siti che caricano molti script esterni, pubblicitari o di tracciamento, perché ogni script aggiunto aumenta la superficie di attacco. ## JWT e OAuth: due cose diverse che si usano insieme JWT non è un protocollo di autorizzazione: è un formato di token. OAuth 2.0 è invece un protocollo che definisce come un’applicazione ottiene il permesso di accedere a risorse per conto di un utente, attraverso flussi di autorizzazione specifici. La confusione nasce perché molti sistemi OAuth usano proprio un JWT come formato dell’access token che rilasciano al termine del flusso di autorizzazione: il JWT è il contenitore, OAuth è la procedura che decide quando e a chi rilasciarlo. Un sistema può usare OAuth con token opachi, non in formato JWT, così come un’applicazione può usare JWT per l’autenticazione interna senza passare da nessun flusso OAuth. Quando ci si chiede se serve “OAuth o JWT”, la domanda da porsi in realtà è un’altra: chi deve autorizzare l’accesso e con quante parti terze deve interfacciarsi l’applicazione. ## Quanto dura un JWT e cosa succede quando scade La durata di un JWT dipende dal valore impostato nella claim exp da chi genera il token: non esiste una durata standard imposta dalla RFC 7519, è una condizione che decide chi implementa il sistema di autenticazione. ### Se la claim exp non viene impostata: il token non scade mai Tecnicamente un JWT senza exp resta valido a tempo indeterminato, perché il server verifica solo la firma e, se presente, la scadenza. La mia posizione è sconsigliarlo quasi sempre: un token che non scade mai, se rubato, resta utilizzabile per sempre, a meno di implementare una revoca manuale lato server. ### Se serve una sessione lunga: usa un refresh token, non un exp lungo Il pattern più diffuso è tenere l’access token con una scadenza breve e affiancargli un refresh token, più longevo e gestito con regole di sicurezza separate, che serve solo a richiedere un nuovo access token quando il precedente scade. Così si limita il danno di un furto senza costringere l’utente a rifare login di continuo. ## Errori frequenti con i JSON Web Token L’errore più frequente è trattare il JWT come se fosse cifrato, mentre è solo codificato in Base64Url: chiunque può decodificarlo con un comando da terminale o un sito di debug, senza conoscere alcun segreto. Un secondo errore ricorrente è inserire nel payload troppe informazioni che cambiano spesso, come ruoli o permessi: se quei dati si aggiornano, il vecchio token continua a contenere i valori precedenti fino alla sua scadenza naturale, e l’utente mantiene permessi che nel frattempo gli sono stati tolti. Un terzo errore è scegliere HMAC per un’architettura con più microservizi indipendenti: il segreto finisce distribuito su più sistemi, e ognuno di essi potrebbe teoricamente firmare token falsi. Per chi sviluppa con framework diversi, la gestione pratica di generazione e verifica cambia da un linguaggio all’altro: la scelta del [framework JavaScript](https://www.conseolente.it/framework-javascript-cosa-sono-come-scegliere/) usato lato server, per esempio, incide su quale libreria conviene adottare per firmare e validare i token. ## Domande frequenti sul JSON Web Token ### Cos’è un JSON Web Token? Un JSON Web Token è una stringa compatta e firmata digitalmente che trasporta informazioni in formato JSON tra un server e un client, usata soprattutto per autenticare le richieste senza salvare sessioni sul server. ### Come si pronuncia JWT? Si pronuncia “jot”, come indicato nella RFC 7519 dagli stessi autori dello standard, anche se nell’uso comune molti lo leggono lettera per lettera senza che questo cambi nulla dal punto di vista tecnico. ### Quali sono le tre parti di un JSON Web Token? Le tre parti sono header, payload e signature, separate da un punto e codificate ciascuna in Base64Url: l’header indica l’algoritmo di firma, il payload contiene le claims, la signature garantisce che il contenuto non sia stato alterato. ### Come funziona un JWT nell’autenticazione? Funziona generando un token al login, che il client invia poi a ogni richiesta nell’header Authorization con lo schema Bearer: il server verifica firma e scadenza senza dover consultare un database a ogni controllo. ### Dove conviene salvare un JWT, cookie o localStorage? Un cookie HttpOnly riduce il rischio di furto tramite script malevoli perché JavaScript non può leggerlo, mentre localStorage semplifica le chiamate verso domini diversi ma espone il token a qualunque script giri sulla pagina. ### JWT e OAuth sono la stessa cosa? JWT è un formato di token, mentre OAuth è un protocollo che definisce come un’applicazione ottiene il permesso di accedere a una risorsa; molti sistemi OAuth usano proprio un JWT come formato dell’access token che rilasciano. ### Un JWT può non scadere mai? Sì, se chi genera il token non imposta la claim exp, il token resta valido a tempo indeterminato: è una condizione sconsigliata, perché un token rubato senza scadenza resta utilizzabile finché non viene revocato manualmente lato server. ### Quali sono i limiti di sicurezza di un JWT? Il payload non è cifrato ma solo codificato, quindi leggibile da chiunque intercetti il token, e non esiste un meccanismo nativo di revoca prima della scadenza: entrambi i limiti vanno gestiti con scelte progettuali specifiche, non risolti dallo standard stesso.