Decodifica JWT Online
Decodifica i token JWT nel tuo browser: nessun dato inviato ad alcun server.
Perché usarlo
Debug dei token JWT all'istante
100% privato
La decodifica avviene nel tuo browser. Il tuo token non lascia mai il tuo dispositivo.
Istantaneo
Decodifica in tempo reale mentre digiti. Nessun pulsante, nessuna attesa.
JSON formattato
Header e payload mostrati come JSON leggibile con evidenziazione della sintassi.
Tutti i tipi JWT supportati
Funziona con HS256, RS256, ES256 e qualsiasi algoritmo dello standard JOSE.
Come funziona
Tre passaggi, senza complicazioni
Incolla il tuo token JWT
Copia e incolla qualsiasi JWT nel campo di input. Il formato è composto da tre parti separate da punti: header.payload.signature.
Decodifica istantanea
L'header e il payload vengono decodificati da Base64URL e mostrati come JSON formattato. Visualizza il tipo di algoritmo, l'emittente, la scadenza e tutte le claim.
Analizza i dati
Esamina ogni campo del payload: iss (emittente), sub (soggetto), exp (scadenza), iat (data di emissione), aud (destinatario) e qualsiasi claim personalizzata.
FAQ
Hai delle domande?
JWT (JSON Web Token) è uno standard aperto (RFC 7519) che definisce un modo compatto e autocontenuto per trasmettere informazioni tra parti come oggetto JSON. Il token è firmato digitalmente, il che consente di verificarne l'autenticità. Viene ampiamente usato per l'autenticazione e l'autorizzazione nelle API REST e nelle applicazioni web moderne.
Quando un utente effettua il login, il server crea un JWT firmato con una chiave segreta (HS256) o una chiave privata (RS256) e lo invia al client. Il client conserva il token (di solito in memoria o nel localStorage) e lo include in ogni richiesta come Authorization: Bearer token. Il server verifica la firma del token senza interrogare un database, rendendo JWT un meccanismo di autenticazione stateless che scala bene nei sistemi distribuiti.
Un JWT è firmato, non cifrato. Questo significa che chiunque può decodificare il payload e leggerne il contenuto: non includere mai password, numeri di carta di credito o dati sensibili nel payload. La firma garantisce l'integrità (nessuno può modificare il token senza invalidarlo), ma non la riservatezza. Se hai bisogno di cifrare il contenuto, usa JWE (JSON Web Encryption).
Le claim sono dichiarazioni sul soggetto del token. Le claim registrate (RFC 7519) includono: iss (issuer, l'emittente), sub (subject, il soggetto), exp (expiration, la scadenza come Unix timestamp), iat (issued at, la data di emissione), aud (audience, il destinatario), nbf (not before, la data di validità iniziale) e jti (JWT ID, identificatore univoco). Oltre a queste, puoi includere qualsiasi claim personalizzata di cui la tua applicazione abbia bisogno.
Non senza invalidarlo. Se modifichi qualsiasi parte dell'header o del payload senza avere la chiave segreta per ri-firmarlo, la firma risultante sarà errata e il server rifiuterà il token. Tuttavia esistono vulnerabilità note: l'attacco alg:none (dove l'header dichiara nessun algoritmo per aggirare la verifica) e la confusione di algoritmi RS256/HS256. Usa sempre una libreria JWT ben mantenuta che gestisca esplicitamente questi casi.
I cookie di sessione memorizzano un ID sul server (con stato), mentre JWT contiene tutte le informazioni nel token stesso (senza stato). JWT scala meglio nelle architetture distribuite e nei microservizi perché non richiede sessioni condivise. Tuttavia JWT presenta degli svantaggi: non puoi revocare un token prima della sua scadenza senza infrastruttura aggiuntiva (blacklist) e, se il token viene rubato, rimane valido fino alla scadenza. Per la maggior parte delle applicazioni web tradizionali, i cookie di sessione httpOnly rimangono la scelta predefinita più sicura.
JWT: storia, struttura tecnica e sicurezza in profondità
JSON Web Token fu standardizzato dall'IETF nel maggio 2015 come RFC 7519, parte del framework JOSE (JSON Object Signing and Encryption). JOSE include anche JWS (JSON Web Signature, RFC 7515), JWE (JSON Web Encryption, RFC 7516), JWK (JSON Web Key, RFC 7517) e JWA (JSON Web Algorithms, RFC 7518). Il lavoro sullo standard iniziò nel 2011, guidato da Mike Jones (Microsoft), John Bradley e Nat Sakimura. Prima di JWT, gli sviluppatori si affidavano a SAML (Security Assertion Markup Language), uno standard basato su XML considerevolmente più verboso e complesso.
Un JWT è composto da tre parti codificate in Base64URL separate da punti. Base64URL si differenzia da Base64 standard sostituendo il simbolo + con - e / con _, omettendo il padding =, rendendolo sicuro per l'uso negli URL e negli header HTTP senza codifiche aggiuntive. L'header specifica il tipo di token (typ: JWT) e l'algoritmo di firma (alg). Gli algoritmi più comuni sono HS256 (HMAC-SHA256, chiave simmetrica), RS256 (RSA-SHA256, chiave asimmetrica), ES256 (ECDSA-SHA256, curva P-256) e il pericoloso none (nessuna firma, che non deve mai essere accettato in produzione).
Le vulnerabilità JWT più critiche sono ben documentate nell'OWASP API Security Top 10. La vulnerabilità alg:none (CVE-2015-9235 in diverse librerie) consente a un attaccante di modificare l'header per dichiarare che non è necessaria alcuna firma, in modo che il server accetti qualsiasi payload arbitrario se la libreria non valida esplicitamente l'algoritmo. La confusione RS256/HS256 si verifica quando un server configurato per RS256 accetta anche HS256: l'attaccante può usare la chiave pubblica RSA (che è per definizione pubblica) come chiave segreta HMAC per firmare token fraudolenti. Le librerie moderne come jose, python-jose e jsonwebtoken risolvono questi problemi richiedendo che l'algoritmo sia specificato esplicitamente al momento della verifica.