Generatore JWT gratuito

Cos'è davvero un JWT

Un JSON Web Token (JWT), pronunciato "jot", è una rappresentazione compatta e URL-safe di affermazioni da trasferire tra due parti. Il formato è composto da tre segmenti codificati in Base64url separati da punti: header.payload.signature. L'header dichiara il tipo di token (sempre JWT) e l'algoritmo di firma (comunemente HS256, RS256 o ES256). Il payload trasporta le affermazioni, un oggetto JSON con campi standard come iss (issuer), sub (subject), aud (audience), exp (scadenza come timestamp Unix), nbf (not before), iat (issued at), jti (JWT ID), oltre a qualunque affermazione specifica dell'applicazione che l'emittente voglia includere. La firma è la prova crittografica che header e payload non sono stati manomessi, prodotta firmando la stringa concatenata base64url(header).base64url(payload) con l'algoritmo e la chiave dichiarati nell'header. JWT è stato specificato da Michael B. Jones, John Bradley e Nat Sakimura come RFC 7519 nel maggio 2015, costruendo sul lavoro precedente di JOSE (JSON Object Signing and Encryption, RFC 7515-7520). Il formato è diventato la forma di token dominante nell'autenticazione web moderna, usato da implementazioni OAuth 2.0 / OIDC, API gateway, token di sessione di applicazioni single-page, autenticazione tra microservizi e gestione delle sessioni basate su cookie del browser su larga scala.

La scelta dell'algoritmo di firma: HS256, RS256 o ES256

JWT supporta diversi algoritmi di firma registrati nel JOSE Algorithms registry (RFC 7518). HS256 (HMAC-SHA256) è il più semplice: un algoritmo simmetrico in cui lo stesso segreto viene usato per firmare e verificare. Economico da calcolare, facile da implementare e appropriato quando firmatario e verificatore sono la stessa parte (per esempio una singola applicazione che emette token di sessione per sé stessa). RS256 (RSA-SHA256) è asimmetrico: la chiave privata firma, la chiave pubblica verifica. Si usa quando emittente e verificatore sono parti diverse; Auth0, Okta, Google Identity Platform, Microsoft Entra ID e la maggior parte dei provider di identità cloud emettono JWT firmati con RS256 perché i client possono verificare la firma usando un endpoint JWKS (JSON Web Key Set) pubblicato senza dover condividere segreti. ES256 (ECDSA P-256 SHA-256) è l'equivalente a curva ellittica di RS256, stesso modello chiave pubblica/privata, chiavi molto più corte (256 bit contro i 2048 minimi di RSA), verifica più veloce. EdDSA (Ed25519) è il successore moderno di ES256, leggermente più veloce e con proprietà crittografiche più pulite; supportato dalle librerie JWT più recenti ma non ancora universale. none è una modalità "senza firma" ammessa dalla specifica JWT che ha causato incidenti di sicurezza in più librerie quando le implementazioni non rifiutavano i token con alg: none; la lezione è che i verificatori JWT devono controllare esplicitamente che l'algoritmo coincida con quello atteso. Questo generatore usa HS256 perché richiede solo un segreto condiviso invece della generazione di chiavi; per usi in produzione di algoritmi asimmetrici, una libreria lato server è lo strumento giusto.

Quando ti serve generare un JWT a mano

• Testare endpoint API. Un'API richiede un JWT nell'header Authorization, per testarla manualmente con curl, Postman o HTTPie ti serve un token. Genera un JWT di test con la forma giusta, firmalo con il segreto condiviso dell'API (in ambienti di sviluppo) e usa il risultato.
• Riprodurre un bug legato ai token. Un utente segnala un problema di autenticazione. Ricostruisci il token che avrebbe ricevuto con le sue affermazioni, esamina la firma, verifica la logica di verifica del tuo servizio contro un token noto-buono e uno noto-cattivo.
• Sviluppo locale senza un provider di autenticazione. Stai costruendo un frontend contro un'API che si aspetta autenticazione JWT, ma non hai ancora accesso al provider di identità di produzione. Genera JWT di test con affermazioni realistiche per lo sviluppo.
• Imparare il formato JWT. Decodifica un JWT, cambia un'affermazione, rifirmalo, vedi cosa fa la tua applicazione. Il ciclo di debug sperimentale è il modo in cui la maggior parte degli sviluppatori arriva a capire la struttura JWT.
• Token interni tra servizi. Due microservizi interni condividono un segreto e usano JWT per autenticare le richieste. Il modello HS256 con segreto condiviso è appropriato qui; questo strumento può generare i token manualmente per i test.

Trappole di sicurezza, dove JWT vanno male

I JWT hanno una lunga storia di errori di implementazione che hanno prodotto incidenti di sicurezza reali. L'attacco "alg: none": le prime librerie JWT accettavano token con il campo algoritmo impostato a "none" (nessuna firma), permettendo a un attaccante di forgiare qualsiasi token. I verificatori devono imporre esplicitamente l'algoritmo atteso. Confusione di algoritmo: un verificatore che accetta sia RS256 sia HS256 può essere ingannato usando la chiave RSA pubblica come segreto HMAC, l'attaccante firma con HS256 usando la chiave pubblica, il verificatore (erroneamente) verifica con HMAC usando la stessa chiave pubblica. I verificatori devono fissare l'algoritmo atteso. Dati sensibili nel payload: le affermazioni JWT sono codificate in Base64 ma non cifrate. Chiunque abbia il token può leggere ogni affermazione. Non mettere mai password, numeri di carta di credito completi o altri segreti nel payload. Nessuna scadenza: i JWT senza un'affermazione exp sono validi per sempre. Imposta sempre una scadenza ragionevole (minuti per gli access token, giorni per i refresh token). Nessuna revoca: i JWT sono autosufficienti, una volta emessi rimangono validi fino a exp indipendentemente dal fatto che l'utente esca, cambi password o veda il proprio account sospeso. O accetti questa limitazione, o mantieni una lista di revoche (che parzialmente vanifica il vantaggio del token stateless), o usi access token a vita breve con rotazione di refresh token. Conservazione in localStorage o cookie: il JWT in localStorage è accessibile a qualsiasi JavaScript in esecuzione sulla pagina (rischio XSS); il JWT in cookie HttpOnly non lo è (ma viene inviato automaticamente con richieste cross-origin, rischio CSRF). Entrambe le opzioni hanno compromessi; le best practice moderne tendono verso cookie HttpOnly con restrizioni SameSite e token CSRF.

JWT, cookie di sessione e PASETO a confronto

JWT non è l'unica scelta. I cookie di sessione tradizionali conservano un ID di sessione opaco; il server tiene lo stato di sessione effettivo in un database o in una cache. Pro: revoca banale (basta cancellare il record lato server), nessun rischio di esporre dati delle affermazioni, nessuna complessità di firma. Contro: richiede una lookup nello store delle sessioni a ogni richiesta (latenza), più difficile da scalare tra servizi. PASETO (Platform-Agnostic Security Tokens, Scott Arciszewski 2018) è un sostituto di JWT progettato per evitare le trappole della confusione di algoritmo e del "none", formato versionato, nessuna negoziazione di algoritmo, firme obbligatorie, scelte di cifrari ristrette. PASETO ha guadagnato terreno in contesti sensibili alla sicurezza ma non ha rimpiazzato JWT nell'ecosistema più ampio. Macaroons (Google, 2014) sono un formato di token più flessibile con restrizioni di capacità concatenate ma sono essenzialmente solo di ricerca nel 2026. OAuth 2.1 consolida le best practice di OAuth 2.0, JWT è ancora il formato tipico per gli access token. La scelta pragmatica nel 2026 rimane JWT per microservizi stateless e token API, cookie di sessione opachi per le tradizionali web app renderizzate dal server, con PASETO come alternativa moderna per nuovi progetti greenfield che vogliono default più solidi.

Domande frequenti

Posso decodificare un JWT senza la chiave segreta?

Sì. I JWT sono firmati ma non crittografati, quindi header e payload possono sempre essere letti. La chiave segreta serve solo per verificare la firma o generare un nuovo token.

È sicuro incollare qui JWT di produzione?

Sì. Tutta l’elaborazione avviene localmente nel tuo browser. I tuoi token e chiavi segrete non vengono mai inviati a un server né archiviati da nessuna parte.

Qual è la differenza tra HS256, RS256 ed ES256?

HS256 usa una chiave segreta condivisa (HMAC-SHA256). RS256 usa coppie di chiavi RSA, ES256 usa la crittografia a curva ellittica. Questo strumento supporta HS256, il più comune per le API web.