Che cos'è un JSON Web Token (JWT)?

Un JSON Web Token è un token compatto e sicuro per gli URL che trasporta claim JSON firmati e permette di verificare le richieste senza sessioni memorizzate. È l’inquadramento della RFC 7519 stessa – “un mezzo compatto e sicuro per gli URL di rappresentare claim da trasferire fra due parti” – e le due idee che contiene reggono tutto quello che segue: il token contiene i propri fatti, e una firma rende quei fatti controllabili da chiunque abbia la chiave giusta, senza alcun database nel giro.

Punti chiave

Un JWT, decodificato

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiJ1c3ItOGZrMiIsInJvbGUi… . dBjftJeZ4CVP…

header     { "alg": "HS256", "typ": "JWT" }
payload    { "sub": "usr-8fk2",  "role": "editor",
             "iss": "https://api.example.com",  "aud": "example-web",
             "iat": 1767024900,  "exp": 1767025800 }        ← durata: 15 minuti
signature  HMACSHA256( base64url(header) + "." + base64url(payload), secret )

Chiunque può DECODIFICARE le prime due parti – Base64Url è imballaggio, non crittografia.
Solo chi ha la chiave può FALSIFICARE la terza – ed è in questo che sta tutto il trucco.

Il contrasto che vale la pena vedere in codice – l’alternativa con stato su cui si misura ogni decisione sui JWT:

// JavaScript / Node.js — Back4app JS SDK
// The stateful contrast: Back4app issues revocable session tokens
const user = await Parse.User.logIn('ada', 'correct-horse-battery');
const token = user.getSessionToken(); // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
await Parse.User.logOut(); // token invalid NOW — no waiting for an exp claim

// Flutter / Dart — Back4app Flutter SDK
// The stateful contrast: Back4app issues revocable session tokens
final user = ParseUser('ada', 'correct-horse-battery', null);
await user.login();
final token = user.sessionToken; // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
await user.logout(); // token invalid NOW — no waiting for an exp claim

// iOS / Swift — Back4app Swift SDK
// The stateful contrast: Back4app issues revocable session tokens
let user = try await User.login(username: "ada", password: "correct-horse-battery")
let token = user.sessionToken // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
try await User.logout() // token invalid NOW — no waiting for an exp claim

// Android / Kotlin — Back4app Android SDK
// The stateful contrast: Back4app issues revocable session tokens
val user = ParseUser.logIn("ada", "correct-horse-battery")
val token = user.sessionToken // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
ParseUser.logOut() // token invalid NOW — no waiting for an exp claim

Come funziona la verifica

La precisione che le spiegazioni saltano: “JWT” nomina il formato dei claim; ciò che tutti fanno realmente circolare è un JWS (RFC 7515) – la serializzazione firmata – mentre JWE è il fratello cifrato, per i payload che devono restare illeggibili. E la verifica sono due lavori, non uno: controllare la firma e poi validare i claim – exp e nbf contro l’orologio, iss contro la propria lista di emittenti consentiti, aud contro l’identificatore di questo servizio. Un token firmato alla perfezione ma scaduto, proveniente dall’emittente sbagliato o coniato per un’altra audience è un attacco firmato alla perfezione.

I claim: il vocabolario del payload

Conviene tenere i payload leggeri per due motivi: i token viaggiano a ogni richiesta negli header (i cookie si fermano intorno ai 4 KB, e ogni claim è banda ripetuta) e tutto ciò che contengono è leggibile da chiunque detenga il token.

JWT vs. token di sessione

La verità fuori moda con cui diverse guide di buone pratiche ormai aprono: per un’app renderizzata lato server con un solo backend, le sessioni del framework sono più semplici e più controllabili – i JWT si guadagnano il posto quando i token devono essere verificati fra servizi o da parti che non possono interpellare l’emittente a ogni richiesta.

Il problema della revoca, onestamente

L’assenza di stato è l’impossibilità di revocare – la stessa proprietà, descritta due volte. Un token firmato è valido fino a exp qualunque cosa sia successa nel frattempo: disconnessione, cambio di password, blocco dell’account. Ogni rimedio reintroduce stato, quindi resta solo da scegliere il gusto: una denylist indicizzata su jti + iss (la costruzione raccomandata da OWASP) consultata a ogni richiesta – poco stato, ma pur sempre stato; il versionamento delle chiavi, che revoca tutti in un colpo solo; oppure l’architettura standard – access token a vita breve (5–15 minuti) più refresh token revocabili con rotazione: ogni rinnovo emette un nuovo refresh token e ritira il vecchio, così che uno rubato muoia al primo riutilizzo, e il riuso di un token ritirato segnala il furto e uccide l’intera famiglia di token. La latenza di revoca diventa allora pari alla vita dell’access token – ed è la vera ragione per cui quelle vite sono brevi.

Scegliere un algoritmo – e gli attacchi a quella scelta

La sezione sugli attacchi per cui esiste la RFC 8725, in tre frasi. alg: "none" è un valore di header legale – le librerie che lo onorano accettano token non firmati. L’attacco per confusione: un verificatore che lascia scegliere l’algoritmo all’header del token può ricevere un token “HS256” firmato con la chiave RSA pubblica del server usata come segreto HMAC – un valore pubblico impiegato come valore privato. Entrambi muoiono allo stesso modo: chi verifica fissa nella configurazione gli algoritmi e le chiavi che accetta e non si fida mai dell’header per la scelta.

Dove conservare i JWT nel browser

Conta il modello di minaccia, non il folklore: localStorage baratta l’immunità al CSRF con il furto via XSS, i cookie barattano l’inverso – ed è per questo che il consenso divide la coppia: access token in memoria, refresh token in un cookie irrobustito.

Casi d’uso tipici

• Autenticazione di API – il bearer token dietro gli header Authorization delle API REST e GraphQL.
• Identità nei microservizi – un solo token emesso dalla gateway e verificato in modo indipendente da ogni servizio, senza archivio di sessioni condiviso.
• ID token di OpenID Connect – l’asserzione di identità firmata di ogni login social – sempre un JWT.
• Passaggi di consegne fra sistemi – link firmati, payload di webhook, autorizzazioni al download: claim verificati da una parte che non può richiamare l’emittente.
• Indizi di autorizzazione stateless – ruoli e ID di tenant trasportati nei claim, con il controllo che fa fede sempre lato server.

JWT o sessioni? Matrice decisionale

Limiti e trade-off

• L’irrevocabilità è strutturale. Ogni mitigazione – denylist, vite brevi, rotazione – è un rientro parziale dello stato che era stato tolto; va messa nel conto prima di scegliere il modello stateless.
• I claim invecchiano. I ruoli sono un’istantanea scattata all’emissione; un amministratore retrocesso resta amministratore fino alla scadenza. Le vite brevi limitano la finestra di obsolescenza.
• Il payload è pubblico. Va trattato come leggibile dall’utente e da qualsiasi ladro di token: identificatori sì, segreti e dati personali no.
• I valori predefiniti delle librerie hanno fatto vittime. Fissare gli algoritmi, validare i claim e controllare typ sono responsabilità della propria configurazione, non garanzie della libreria.
• La dimensione si accumula. Ogni claim viaggia a ogni richiesta; payload generosi tassano la banda mobile e possono sforare i limiti dei cookie.

I token su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. La scelta della piattaforma stessa illustra la matrice decisionale: le sessioni dei client usano token di sessione revocabili, lato server – le schede di codice qui sopra – così che disconnessione, cambi di password e chiusura della sessione dalla dashboard abbiano effetto immediato, senza finestre di scadenza da attendere. I JWT compaiono dove è giusto che siano: gli ID token OIDC dei provider di identità vengono verificati lato server dagli adattatori di autenticazione durante il login social, e le funzioni Cloud Code possono coniare o verificare JWT per i passaggi di consegne con terze parti usando librerie standard – con il segreto di firma nella configurazione lato server, mai spedito ai client. Con stato dove conta il controllo, stateless ai bordi dove la verifica deve viaggiare: l’architettura che questo articolo difende, già assemblata.