JWT (JSON Web Token) è uno standard aperto definito dall'IETF nella RFC 7519 (la RFC 7515 descrive la forma di firma JWS, la RFC 7516 descrive la crittografia JWE, la RFC 7517 definisce le chiavi JWK) per trasferire in modo sicuro informazioni utente 'asserite' tra richieste HTTP, flussi OIDC e chiamate di microservizi. Una stringa JWT standard è composta da tre segmenti codificati in Base64URL: Header (algoritmo e tipo), Payload (Claims, i dati utente) e Signature (una firma basata su chiave sui primi due). I tre segmenti sono uniti da un punto letterale `.`, ad esempio `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT non è crittografia.** Questo è l'equivoco più comune. Il Payload è in testo chiaro per impostazione predefinita — chiunque può decodificarlo con Base64URL e leggerne il contenuto. JWT fornisce **rilevamento di manomissione**, non riservatezza: il server firma di nuovo Header.Payload con la chiave condivisa e la confronta con la Signature del token. Se corrispondono, il token non è stato alterato in transito. Questa è la metafora del 'biglietto del treno con un timbro anti-contraffazione': all'ispettore importa se il biglietto è genuino, non se il codice QR è illeggibile.
JWT divide chiaramente le responsabilità tra 13 algoritmi. **Famiglia HMAC** (HS256/HS384/HS512) usa una chiave simmetrica sia per firmare che per verificare, veloce e semplice, adatta a un singolo servizio o a un cluster affidabile; il secret deve essere almeno lungo quanto il digest (ad esempio, ≥ 32 byte per HS256). **Famiglia RSA** (RS256/RS384/RS512) usa RSASSA-PKCS1-v1_5, lo schema asimmetrico più comune — i firmatari detengono la chiave privata, i verificatori detengono la chiave pubblica. **Famiglia RSA-PSS** (PS256/PS384/PS512) usa il padding RSA-PSS più recente con garanzie di sicurezza più forti, preferito da AWS SigV4 e dai provider di identità OIDC moderni. **Famiglia ECDSA** (ES256/ES384/ES512) usa curve ellittiche (P-256/P-384/P-521 rispettivamente) con firme più corte e prestazioni migliori. **EdDSA** (principalmente Ed25519) è estremamente veloce e deterministico (stesso messaggio + stessa chiave = stessa firma ogni volta) ed è l'algoritmo raccomandato in OAuth 2.1 e nei nuovi protocolli.
La sicurezza è dove JWT inciampa in produzione. La OWASP JWT Cheat Sheet evidenzia almeno quattro regole ferree: (1) non mettere mai password, documenti di identità, numeri di carta o chiavi API in testo chiaro nel Payload; (2) il server **non deve mai fidarsi del campo alg** dichiarato nell'Header del Token — deve verificare con un algoritmo codificato, altrimenti un attaccante che riscrive l'header a `alg: none` aggira tutto (questa è la radice di CVE storici come CVE-2015-9235); (3) i secret HMAC devono essere casuali e lunghi almeno 32 byte, mai stringhe corte; (4) la verifica è più che controllare le firme — devi anche convalidare `exp` (scadenza), `nbf` (non prima), `iss` (emittente) e `aud` (pubblico). Questo strumento evidenzia ciascuno di questi Claims nell'interfaccia utente per poter dire a colpo d'occhio se un fallimento è un problema di firma, un problema di temporizzazione o un problema di Claims.
JWT non è un sostituto delle sessioni. Le sessioni memorizzano lo stato dell'utente sul server (Redis o un database); JWT impacchetta lo stato nel token. Le architetture di microservizi, le API senza stato, i client mobili e le configurazioni con molto CORS traggono vantaggio da JWT; i sistemi aziendali tradizionali e i flussi che richiedono la revoca istantanea (ad esempio, 'espelli questo utente ora') sono ancora meglio serviti dalle sessioni. Questo strumento copre sia il debug JWT puro che i passaggi di analisi del Token / verifica della firma / modifica del Payload di una migrazione da sessione a JWT.