JWT (JSON Web Token) è un formato compatto per trasmettere dati firmati, il più delle volte informazioni su un utente autenticato. Un token è composto da tre parti separate da punti: header.payload.signature. Nel panorama italiano è comune trovarlo sia in stack PHP/Laravel per PMI ed e-commerce, sia in ambienti Java/Spring per la pubblica amministrazione e il settore bancario.
Il codice fiscale come dato sensibile nei claims
Un errore frequente in sistemi italiani è inserire il codice fiscale direttamente in un claim del payload, ad esempio {"cf": "RSSMRA80A01H501U"}. Dato che header e payload si decodificano senza alcuna chiave, chiunque intercetti il token può leggere il codice fiscale in chiaro, anche se la firma è del tutto valida e non falsificabile — motivo per cui è preferibile mettere in claim solo un identificativo interno, non dati sensibili come il codice fiscale stesso.
Le tre parti di un token
- Header — un JSON con il tipo di token e l'algoritmo di firma (ad esempio HS256 o RS256), codificato in Base64URL.
- Payload — un JSON con i "claims": dati sull'utente, momento di emissione, scadenza, ecc., anch'esso in Base64URL.
- Signature — una firma calcolata su header e payload con una chiave segreta o privata, che conferma che il token non è stato alterato.
Accenti italiani nei claims: perché e dove
Un payload come {"nome": "Perché Città"} — con è, à, ò tipici dell'italiano — si codifica in Base64URL esattamente come qualsiasi altro JSON, dato che il processo lavora su byte UTF-8. Ogni lettera accentata occupa 2 byte anziché 1, quindi un token con nomi e città italiane reali risulta leggermente più lungo del suo equivalente in puro ASCII inglese.
Base64URL, non Base64 normale
JWT usa una variante di Base64 con un alfabeto sicuro per gli URL: i caratteri + e / sono sostituiti da - e _, e il riempimento = viene solitamente omesso. Questo permette di inserire un token in un URL o in un header senza codifica aggiuntiva.
Una distinzione importante: decodificare ≠ verificare
Header e payload sono solo Base64URL: chiunque può decodificarli e leggerne il contenuto senza alcuna chiave. Ci si può fidare del contenuto di un token solo dopo averne verificato la firma con la chiave corrispondente — e questa verifica la esegue il server, non un client che si limita a guardare cosa c'è dentro il token.
Attacco pericoloso: sostituzione dell'algoritmo con «none»
La specifica JWT permette l'algoritmo none — un token senza firma. Se il backend si fida ingenuamente del campo alg nell'header del token invece di verificare la firma con un algoritmo fisso e noto in anticipo, un attaccante può sostituire alg con none, eliminare la firma. Le librerie JWT affidabili richiedono di specificare esplicitamente l'algoritmo atteso al momento della verifica.