JWT: comprendere struttura, firma, scadenza ed errori comuni

Un JSON Web Token viene spesso usato per trasportare informazioni tra sistemi. Il suo formato compatto può sembrare cifrato o intrinsecamente affidabile, ma non lo è.

Tre parti, generalmente leggibili

Un JWT classico contiene header, payload e firma separati da punti. Le prime due parti sono codificate, non necessariamente cifrate. Non inserire quindi segreti nel payload pensando che siano invisibili.

Un decoder o inspector permette di leggere localmente i campi del token, ma questa operazione descrive soltanto il contenuto.

Decodificare non significa verificare

Mostrare il payload prova soltanto che la stringa può essere interpretata secondo il formato. Per fidarsi dei claim, l’applicazione deve verificare la firma con la chiave e l’algoritmo attesi e poi applicare i propri controlli.

Cosa prova la firma

La firma viene calcolata a partire dalle parti codificate del token e da una chiave secondo l’algoritmo scelto. Se verificata correttamente, permette di rilevare modifiche e di stabilire che il token è stato firmato da un’entità che possiede la chiave attesa. Non rende il payload confidenziale.

Algoritmi simmetrici come HS256 utilizzano un segreto condiviso; famiglie asimmetriche come RS256 o ES256 separano la chiave privata di firma dalla chiave pubblica di verifica.

L’applicazione deve imporre gli algoritmi accettati e non fidarsi ciecamente del valore dichiarato nel token.

Scadenza, audience ed emittente

Claim come exp, nbf, iat, iss e aud sono utili soltanto se vengono davvero verificati. Accettare un token scaduto, destinato a un’altra audience o emesso da un soggetto inatteso può annullare una parte fondamentale della protezione.

Una piccola tolleranza per differenze di orologio tra sistemi può essere ragionevole, ma non deve trasformarsi in un prolungamento eccessivo della validità.

Token brevi e rinnovo

Ridurre la durata di un access token limita la finestra disponibile in caso di furto, ma richiede una strategia di rinnovo. I refresh token, quando esistono, sono segreti di grande valore e devono essere protetti e revocabili secondo l’architettura.

La revoca è meno naturale con un token completamente autonomo rispetto a una sessione conservata lato server. Questo non rende JWT una cattiva scelta, ma è un compromesso da comprendere.

Dove conservare un token nel browser?

Non esiste una risposta universale. Uno storage accessibile a JavaScript è esposto in caso di XSS. Un cookie HttpOnly riduce questo accesso ma introduce considerazioni su cookie, SameSite e CSRF.

La scelta dipende dal modello di minaccia e dalla comunicazione tra client e backend. Evita in ogni caso di mettere JWT negli URL, dove possono finire in cronologia, log e referrer.

JWT è solo una componente

Gestione della sessione, revoca, storage client, CSRF, XSS e durata dei token restano decisioni di architettura. Un JWT valido non dice automaticamente se l’utente ha il diritto di eseguire una determinata azione.

Autenticazione e autorizzazione sono diverse: anche dopo aver verificato il token, il server deve controllare i permessi richiesti dalla risorsa.

Errori frequenti

Tra gli errori comuni troviamo:

• accettare un algoritmo inatteso;
• non verificare iss o aud;
• usare chiavi deboli;
• dare ai token una durata eccessiva;
• inserire dati sensibili nel payload;
• fidarsi di un ruolo dichiarato senza controllare l’autorizzazione lato server.

Gli strumenti JWT sono ottimi per imparare, ispezionare e creare dati di test. Non trasformano però, da soli, un sistema di autenticazione in un sistema sicuro.

Per inserire JWT nel contesto dei flussi di autorizzazione moderni e capire PKCE, JWK e JWKS, consulta OAuth 2.0, PKCE, JWT, JWK e JWKS.