Quando sviluppiamo un'applicazione web moderna, prima o poi ci troviamo davanti alla necessità di gestire l'autenticazione degli utenti.
Un sito tradizionale può utilizzare una sessione conservata sul server e identificata attraverso un cookie.
Un'applicazione con frontend separato, un servizio mobile o un'architettura basata su API potrebbe invece utilizzare token di accesso.
Tra i formati più conosciuti troviamo i JWT, JSON Web Token.
Sono molto diffusi perché permettono di rappresentare informazioni in un formato compatto e facilmente trasportabile attraverso HTTP.
La loro semplicità, però, può portare a sottovalutare alcuni aspetti di sicurezza.
Un JWT non è automaticamente sicuro soltanto perché è firmato, e una gestione sbagliata può compromettere l'intero sistema di autenticazione.
Che cos'è un JWT?
Un JSON Web Token è un formato standard per rappresentare un insieme di informazioni, chiamate claim, all'interno di un token JSON.
Queste informazioni possono riguardare, per esempio, l'identificatore di un utente, il soggetto che ha emesso il token oppure la sua scadenza.
Un JWT viene spesso utilizzato come credenziale di accesso alle API.
Dopo l'autenticazione, il server può emettere un token che il client utilizzerà nelle richieste successive.
È importante distinguere il formato JWT dal protocollo di autenticazione.
JWT non è un sistema di login completo: è un formato che può essere utilizzato all'interno di sistemi di autenticazione e autorizzazione.
Com'è fatto un JSON Web Token?
Un JWT firmato nella forma compatta più comune è composto da tre parti separate da un punto:
header.payload.signature
Le prime due parti contengono dati codificati in Base64URL.
La terza rappresenta la firma crittografica.
Header
L'header descrive alcune caratteristiche del token, tra cui l'algoritmo utilizzato per la firma.
Un esempio:
{
"alg": "RS256",
"typ": "JWT"
}
Payload
Il payload contiene i claim.
Per esempio:
{
"sub": "user_123",
"iss": "https://auth.example.com",
"aud": "https://api.example.com",
"iat": 1790000000,
"exp": 1790003600
}
In questo esempio:
subidentifica il soggetto del token.issindica chi lo ha emesso.audidentifica il destinatario previsto.iatrappresenta il momento di emissione.expindica la scadenza.
I valori temporali sono espressi come timestamp Unix.
Signature
La firma permette al destinatario di verificare l'integrità del token e, secondo l'algoritmo utilizzato, la sua autenticità rispetto alla chiave attesa.
Se il payload viene modificato senza possedere la chiave necessaria, la verifica della firma dovrebbe fallire.
Un JWT è cifrato?
Questa è una delle domande più importanti.
Un JWT firmato non è necessariamente cifrato.
Le informazioni presenti nel payload di un normale JWT firmato possono essere decodificate da chiunque possieda il token.
La codifica Base64URL non è una tecnica di cifratura.
Di conseguenza, non dovresti inserire nel payload password, segreti, dati personali non necessari o informazioni che devono rimanere riservate.
Esistono anche token cifrati secondo lo standard JWE, ma non bisogna confonderli con i comuni JWT firmati.
Come viene utilizzato un JWT nelle API?
Immaginiamo un'applicazione che espone un'API protetta.
Il processo può essere il seguente:
- L'utente si autentica.
- Il server verifica le credenziali.
- Il sistema emette un access token.
- Il client conserva il token secondo la propria architettura.
- Il client include il token nelle richieste protette.
- Il server verifica il token prima di autorizzare l'operazione.
Una richiesta HTTP potrebbe essere:
GET /api/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer <ACCESS_TOKEN>
Il server deve verificare non soltanto la firma, ma anche i claim rilevanti e i permessi necessari per accedere alla risorsa richiesta.
Gli errori di sicurezza più comuni con i JWT
Accettare algoritmi non previsti
Uno degli errori storicamente più conosciuti riguarda la gestione dell'algoritmo di firma.
Alcune implementazioni vulnerabili hanno accettato token con algoritmi non consentiti o hanno gestito in modo scorretto la scelta dell'algoritmo.
Un server non dovrebbe fidarsi automaticamente del valore alg ricevuto nel token.
Gli algoritmi accettati devono essere configurati esplicitamente dall'applicazione e associati al tipo corretto di chiave.
È fondamentale utilizzare librerie affidabili e aggiornate.
Non verificare la scadenza
Il claim exp indica fino a quando il token può essere considerato valido.
Se il server non lo controlla correttamente, un token potrebbe rimanere utilizzabile oltre il periodo previsto.
Una scadenza ragionevolmente breve limita la durata dell'esposizione in caso di furto.
La durata ideale dipende dal contesto e dal rischio associato al servizio.
Non controllare issuer e audience
Verificare la firma non basta sempre.
Un token potrebbe essere stato emesso legittimamente, ma per un'applicazione differente.
Per questo motivo, è importante verificare i claim iss e aud quando previsti dall'architettura.
Il server deve assicurarsi che il token provenga dall'emittente autorizzato e sia destinato proprio al servizio che lo sta ricevendo.
Utilizzare chiavi di firma deboli
Quando vengono utilizzati algoritmi simmetrici come HS256, la sicurezza dipende anche dalla robustezza del segreto condiviso.
Una chiave corta, prevedibile o riutilizzata in ambienti differenti può compromettere la protezione.
Le chiavi devono essere generate attraverso meccanismi crittograficamente sicuri e conservate in modo appropriato.
Inserire troppe informazioni nel payload
Un JWT dovrebbe contenere soltanto i claim realmente necessari.
Aggiungere dati personali o informazioni applicative superflue aumenta l'esposizione e può creare problemi quando i dati cambiano ma il token rimane valido.
Dove conservare i JWT nel browser?
Non esiste una risposta universale.
La scelta dipende dall'architettura, dal modello di minaccia e dalle modalità di utilizzo dell'applicazione.
LocalStorage
Il LocalStorage permette a JavaScript di conservare informazioni nel browser.
È comodo, ma presenta un problema importante: se un attaccante riesce a eseguire JavaScript malevolo attraverso una vulnerabilità XSS, potrebbe accedere ai token conservati.
Per questo motivo, memorizzare access token sensibili nel LocalStorage richiede particolare cautela.
Cookie HttpOnly
Un cookie con attributo HttpOnly non può essere letto direttamente dal normale JavaScript della pagina.
Questo può ridurre il rischio di sottrazione diretta del token attraverso alcune forme di XSS.
Tuttavia, se il cookie viene inviato automaticamente dal browser, bisogna considerare anche le protezioni CSRF.
Gli attributi Secure e SameSite devono essere configurati in modo coerente con l'applicazione.
Memoria dell'applicazione
Un'altra possibilità consiste nel mantenere temporaneamente l'access token in memoria, evitando una persistenza prolungata nel browser.
Questa soluzione può ridurre alcuni rischi, ma richiede una gestione attenta della durata della sessione e del rinnovo dei token.
Access token e refresh token: qual è la differenza?
In molti sistemi vengono utilizzati due tipi di credenziali.
L'access token serve ad autorizzare le richieste verso le API e ha generalmente una durata limitata.
Il refresh token permette di richiedere un nuovo access token senza obbligare l'utente a effettuare nuovamente il login.
Il refresh token è particolarmente sensibile perché può consentire di prolungare l'accesso.
Dovrebbe quindi essere conservato con attenzione e, quando l'architettura lo prevede, protetto attraverso rotazione, rilevamento del riutilizzo e possibilità di revoca.
Non tutti i sistemi hanno bisogno di refresh token: la scelta dipende dalle esigenze dell'applicazione.
Come revocare un JWT?
Uno dei limiti dei token autosufficienti è che possono rimanere validi fino alla scadenza anche dopo un evento come il logout, se il server non utilizza meccanismi aggiuntivi.
Per gestire questa situazione si possono adottare diverse strategie.
Per esempio:
- Access token con durata breve.
- Revoca dei refresh token.
- Liste di revoca o controlli centralizzati quando necessari.
- Versionamento delle sessioni o delle credenziali.
- Rotazione delle chiavi nei casi appropriati.
Non esiste una soluzione perfetta per ogni scenario.
Un sistema con esigenze di revoca immediata potrebbe richiedere controlli server-side che riducono parte dei vantaggi di un token completamente autonomo.
JWT e autorizzazione: attenzione ai permessi
Un errore frequente consiste nel considerare sufficiente la presenza di un JWT valido per autorizzare qualsiasi operazione.
Ma autenticazione e autorizzazione sono concetti differenti.
Un token può dimostrare che una richiesta proviene da un soggetto autenticato, senza necessariamente autorizzarlo ad accedere a qualsiasi risorsa.
Supponiamo che un utente richieda:
GET /api/orders/987
Authorization: Bearer <ACCESS_TOKEN>
Il server deve verificare che quell'utente possa realmente consultare l'ordine 987.
Non basta verificare che il token sia valido.
Questo controllo è fondamentale per prevenire vulnerabilità come BOLA, Broken Object Level Authorization.
Come gestire i JWT in modo sicuro
Una buona implementazione dovrebbe partire da alcune regole fondamentali.
Utilizza librerie mature, aggiornate e progettate per gestire correttamente la verifica dei token.
Configura esplicitamente gli algoritmi consentiti e le chiavi attese.
Verifica scadenza, emittente, destinatario e gli altri claim richiesti dal tuo sistema.
Proteggi le credenziali durante la trasmissione attraverso HTTPS.
Evita di includere informazioni sensibili nel payload e limita la durata dei token secondo le esigenze dell'applicazione.
Infine, definisci una strategia chiara per logout, revoca, rinnovo e gestione delle chiavi.
Per approfondire, puoi consultare la JWT Cheat Sheet di OWASP e lo standard RFC 8725 dedicato alle buone pratiche di sicurezza JWT.
Conclusione
I JSON Web Token sono strumenti molto utili per realizzare sistemi di autenticazione e comunicazione tra servizi.
Ma la loro sicurezza dipende dalle scelte implementative.
Una firma valida non sostituisce la verifica dei permessi, una scadenza configurata non elimina il rischio di furto e un token codificato non protegge la riservatezza dei dati.
La regola più importante è considerare i JWT come credenziali sensibili, non come semplici contenitori di informazioni.
Con MiHakero puoi integrare queste buone pratiche con il monitoraggio delle esposizioni esterne e delle configurazioni dei servizi pubblici. La verifica della logica di autenticazione e autorizzazione dei JWT richiede invece test applicativi specifici.
SEO Meta Title: JWT: come funzionano e quali rischi evitare
SEO Meta Description: Scopri come funzionano i JSON Web Token, dove conservarli, come verificarli e quali errori evitare per proteggere le API.