Why doesn't this tool verify the JWT signature?

Signature verification requires the signing secret or public key, which is kept private on your server. This tool decodes and displays the header and payload for inspection, but cryptographic verification must happen on your backend. Never trust an unsigned or unverified JWT in production.

What information can I see in a JWT payload?

The payload contains claims (data assertions) such as: exp (expiration time), iss (issuer), sub (subject/user), aud (audience), and custom claims. Always check the exp claim to ensure the token hasn't expired. Additional claims depend on how the token was issued.

Is this tool secure for sensitive data?

Yes, all processing runs entirely in your browser. No data is sent to any server, making it safe for sensitive information.

Decodificatore JWT gratuito

Decodifica e ispeziona i JSON Web Tokens · intestazione, payload, claim e scadenza.

Incolla token JWT

Intestazione

Payload

Firma

Informazioni sui JWTs

I JSON Web Tokens (JWTs) sono un modo compatto per rappresentare claim tra due parti. Sono composti da tre parti: un'intestazione (algoritmo e tipo), un payload (claim come emittente, scadenza, soggetto) e una firma. Questo strumento decodifica l'intestazione e il payload ma non verifica le firme · per questo, è necessario il segreto di firma o la chiave pubblica. Tutta la decodifica avviene nel tuo browser; il tuo token non viene mai inviato da nessuna parte.

Una breve storia dei JSON Web Token

Il JSON Web Token (JWT) è stato standardizzato come RFC 7519 nel maggio 2015 da Michael B. Jones (Microsoft), John Bradley (Ping Identity) e Nat Sakimura (NRI) sotto il Gruppo di Lavoro JOSE dell'IETF. Fu il culmine di mezzo decennio di lavoro: il primo internet-draft JWT apparve nel dicembre 2010, sviluppandosi dal pesante formato di asserzione basato su XML di SAML 2.0 (2005) e dalla sentita necessità di qualcosa di più leggero che i browser potessero analizzare nativamente. La svolta fu scegliere JSON anziché XML e base64url anziché PEM: un JWT poteva stare in una stringa di query URL o in un header Authorization: Bearer. L'intera famiglia JOSE fu consegnata come un set coordinato: RFC 7515 (JWS) per la firma, RFC 7516 (JWE) per la crittografia, RFC 7517 (JWK) per il formato chiave, RFC 7518 (JWA) per gli identificatori di algoritmo e RFC 7519 (JWT) per il livello delle dichiarazioni, tutto lo stesso giorno di maggio 2015. L'adozione fu istantanea. OAuth 2.0 (RFC 6749, 2012) aveva standardizzato i token di accesso ma lasciato il loro formato opaco; l'industria scelse JWT. OpenID Connect (dicembre 2014, OpenID Foundation) rese JWT obbligatorio per i token ID. Entro il 2017 ogni grande provider di identità (Auth0, Okta, Azure AD, AWS Cognito, Google Identity, Firebase Auth) emetteva JWT come formato di sessione nativo. JWT.io, il sito web decodificatore lanciato da Auth0 nel 2014, divenne lo strumento de facto per il debug JWT e contribuì a cementare la quota di mente degli sviluppatori per il formato. Due incidenti di sicurezza hanno plasmato il modello di minaccia moderno: la divulgazione di Tim McLean del 2015 del bypass alg: none e dell'attacco di confusione di algoritmo HS/RS, e CVE-2022-21449 (aprile 2022), il bug «Psychic Signatures» di Neil Madden nel verificatore ECDSA di Java 15-18. Entrambi hanno portato all'indurimento predefinito delle librerie: la maggior parte delle librerie moderne ora rifiuta alg: none a priori e fissa l'algoritmo previsto invece di leggerlo dall'header del token.

L'anatomia di un JWT

Tre segmenti codificati in base64url. Un JWT è la stringa header.payload.signature: tre segmenti separati da punti, ciascuno codificato in base64url. RFC 7519 lo chiama JWT Compact Serialization. Il tutto entra in un URL o in un header HTTP; quella compattezza era l'obiettivo di design che distingueva JWT dai predecessori basati su XML come SAML.
Header. Un piccolo oggetto JSON che normalmente contiene due campi: alg (l'algoritmo di firma, es. HS256, RS256, ES256) e typ (quasi sempre «JWT»). I campi opzionali includono kid (un identificatore di chiave usato per la rotazione delle chiavi) e cty (tipo di contenuto per token annidati). L'header dice al verificatore come validare la firma; non fidatevene mai da solo, fissate sempre l'algoritmo previsto lato server.
Payload. Un oggetto JSON di dichiarazioni, asserzioni chiave-valore su un soggetto. RFC 7519 §4.1 riserva sette dichiarazioni standard: iss (emittente), sub (soggetto), aud (audience), exp (scadenza), nbf (non prima), iat (emesso a) e jti (ID JWT univoco). Gli emittenti aggiungono liberamente dichiarazioni personalizzate. Il payload è firmato ma non crittografato: chiunque abbia il token può leggerlo.
Firma. La prova crittografica che l'header e il payload non sono stati manomessi. L'input di firma è la stringa letterale base64url(header) + "." + base64url(payload); la firma stessa viene poi codificata in base64url come terzo segmento. La verifica richiede il segreto simmetrico (HS*) o la chiave pubblica asimmetrica (RS*, ES*, PS*, EdDSA) e deve sempre avvenire su un server fidato.
base64url, non base64. I segmenti JWT usano la variante base64 URL-safe definita in RFC 4648 §5: il carattere 62 è - invece di +, il carattere 63 è _ invece di /, e il padding finale = viene rimosso. L'atob() integrato di JavaScript gestisce solo base64 standard, quindi i decoder JWT traducono l'alfabeto e ri-pad prima di decodificare.
NumericDate: secondi, non millisecondi. RFC 7519 definisce exp, nbf e iat come «il numero di secondi da 1970-01-01T00:00:00Z UTC». Date.now() di JavaScript restituisce millisecondi, quindi un bug comune è un exp tre ordini di grandezza troppo grande, producendo un token che «scade» intorno all'anno 53.000. Usate sempre Math.floor(Date.now() / 1000) quando coniate token.

Dove vengono usati i JWT in pratica

Token di accesso OAuth 2.0. RFC 6749 ha lasciato il formato del token di accesso opaco, ma in pratica l'industria si è standardizzata su JWT. Auth0, Okta, Azure AD, AWS Cognito e Google Identity emettono tutti token di accesso JWT per impostazione predefinita. Il token Bearer nel vostro header Authorization è quasi sempre un JWT.
Token ID OpenID Connect. OIDC (dicembre 2014) impone JWT per il suo id_token. L'id_token porta dichiarazioni di identità sull'utente autenticato (sub, email, name, picture) ed è consumato dalla parte affidante invece di essere passato avanti. Questo è il meccanismo principale dietro «Accedi con Google», «Accedi con Apple» e flussi equivalenti.
Autenticazione API. Le API REST senza stato adottano JWT perché rimuove la necessità di uno store di sessione lato server: l'API si fida di ciò che la firma verifica. Le chiavi API stile Stripe rimangono comuni per il traffico server-a-server, ma per le API a scopo utente, il pattern Authorization: Bearer <jwt> è ora l'impostazione predefinita.
Autenticazione microservizio-a-microservizio. Un JWT a scopo utente coniato al bordo dell'API viene inoltrato attraverso chiamate interne servizio-a-servizio, permettendo a ogni servizio di fidarsi dell'autenticazione originale senza ri-autenticarsi. Il pattern è talvolta chiamato «traduzione di token»: il gateway di bordo scambia una sessione opaca con un JWT di breve durata con scope sulla chiamata downstream.
Sessioni di applicazioni a pagina singola. Le SPA (React, Vue, Angular) storicamente hanno memorizzato i token di accesso in localStorage per comodità. La guida moderna (OWASP, Auth0) è di mantenere i token di accesso in memoria e i token di refresh in cookie HttpOnly + Secure + SameSite=Strict, perché localStorage è leggibile da qualsiasi XSS che atterra sulla pagina.
Sessioni di app mobili. Le app iOS e Android memorizzano i token di accesso nel Keychain o Keystore della piattaforma. Il token viene inviato come Authorization: Bearer a ogni chiamata backend. I token di refresh vengono ruotati a ogni uso, e il breve exp del token di accesso (tipicamente 5-15 minuti) è la principale difesa contro il replay da dispositivo rubato.

Standard e pietre miliari della sicurezza

RFC 7519 (JWT, maggio 2015). La specifica base. Definisce la JWT Compact Serialization, le sette dichiarazioni standard registrate (iss, sub, aud, exp, nbf, iat, jti) e il formato NumericDate. Autori: Michael B. Jones, John Bradley, Nat Sakimura.
RFC 7515 (JWS, maggio 2015). JSON Web Signature. Il formato wrapper firmato che quasi tutti chiamano informalmente «JWT»: tre segmenti base64url uniti da punti. JWS supporta sia la forma compatta che la JSON Serialization; JWT usa solo la forma compatta.
RFC 7516 (JWE, maggio 2015). JSON Web Encryption. La variante crittografata con cinque segmenti (header, chiave crittografata, IV, ciphertext, tag di autenticazione). Usate JWE, non JWS, quando il payload deve essere riservato, non solo evidente alla manomissione.
RFC 7517 (JWK, maggio 2015). JSON Web Key. La rappresentazione JSON delle chiavi crittografiche. L'endpoint JWKS (/.well-known/jwks.json) pubblica un JSON Web Key Set, il meccanismo moderno per la rotazione di chiavi senza tempo di inattività: i verificatori cercano le chiavi per kid.
RFC 7518 (JWA, maggio 2015). JSON Web Algorithms. Il registro degli identificatori alg: HS256/384/512 (HMAC), RS256/384/512 (RSASSA-PKCS1-v1_5), ES256/384/512 (ECDSA), PS256/384/512 (RSASSA-PSS), EdDSA (Ed25519/Ed448) e il (intenzionalmente raramente usato) none.
Il bypass alg: none (Tim McLean, 2015). RFC 7518 elenca none come un valore di algoritmo valido per contesti non protetti. I verificatori ingenui accettavano un token con l'header riscritto a {"alg":"none"} e una firma vuota, permettendo a un attaccante di falsificare qualsiasi payload. Le librerie moderne rifiutano none per impostazione predefinita; la specifica stessa afferma che i verificatori «NON DEVONO accettare JWS non protetti per impostazione predefinita».
Attacco di confusione di algoritmo HS/RS (Tim McLean, 2015). Se un verificatore sceglie l'algoritmo dall'header del token invece di fissarlo, un attaccante può riscrivere l'header a HS256 e firmare il token usando la chiave pubblica RSA del server come segreto HMAC. La libreria vede HS256, tratta la chiave pubblica RSA configurata come un segreto simmetrico, e la firma è valida. Mitigazione: fissate l'algoritmo previsto out-of-band; non derivatelo mai dal token.
CVE-2022-21449 «Psychic Signatures» (Neil Madden, aprile 2022). Il verificatore ECDSA di Java 15-18 non controllava che i valori r e s della firma fossero diversi da zero, il che significa che una firma letteralmente tutta a zero era accettata come valida. I JWT firmati con ES256/384/512 su JVM affette potevano essere falsificati con una firma vuota. Patchato nel Critical Patch Update di Oracle di aprile 2022.

Altre domande frequenti

Perché questo strumento non verifica la firma?

La verifica ha bisogno di un segreto (HMAC) o di una chiave pubblica (RSA / ECDSA / EdDSA). Incollare un segreto HMAC di produzione in qualsiasi sito web è di per sé una fuga di credenziali, anche su uno strumento che giura di non trasmettere nulla. La verifica appartiene a un server che controllate. Il lavoro del decoder è rendere il contenuto leggibile in modo che possiate vedere cosa il vostro verificatore dovrebbe controllare.

È sicuro incollare qui veri token di produzione?

La decodifica avviene interamente nel vostro browser. Il token non viene inviato sulla rete, scritto in alcun log, o memorizzato da nessuna parte. Detto questo, un JWT spesso è una credenziale: chiunque detenga un token di accesso non scaduto può agire come l'utente. La convenzione della comunità è «trattate un JWT di produzione come un cookie di sessione»: preferite token di test quando potete, e ruotate qualsiasi token reale abbiate condiviso fuori dalla sessione del browser che l'ha coniato.

Dove dovrei memorizzare un JWT nel browser?

I due pattern comuni hanno ciascuno un compromesso. localStorage è conveniente ma leggibile da qualsiasi attacco XSS riuscito sulla pagina. I cookie con HttpOnly sono invisibili a JavaScript quindi XSS non può leggerli, ma hanno bisogno di SameSite=Strict o SameSite=Lax per evitare CSRF. La migliore pratica attuale: token di accesso a breve durata in una variabile JavaScript (solo memoria) più un token di refresh a lunga durata in un cookie HttpOnly + Secure + SameSite=Strict con scope sull'endpoint di refresh, ruotato a ogni uso.

Cosa fa il campo kid nell'header?

Identifica quale chiave ha firmato il token. I provider di identità moderni pubblicano le loro chiavi pubbliche a un endpoint /.well-known/jwks.json come un JWK Set (RFC 7517); il verificatore cerca la chiave il cui kid corrisponde all'header del token. Questo è ciò che rende possibile la rotazione di chiavi senza tempo di inattività: sia le chiavi vecchie che nuove possono coesistere nel JWKS durante il periodo di grazia.

Posso revocare un JWT una volta emesso?

Non nativamente. Un JWT firmato è valido fino alla sua dichiarazione exp; quella mancanza di stato è la proprietà principale del formato. Soluzioni alternative: mantenere i token di accesso brevi (5-15 minuti) abbinati a un token di refresh revocabile; mantenere un elenco di negazione lato server dei valori jti revocati; ruotare la chiave di firma (che invalida ogni token in sospeso firmato con essa). Ogni opzione re-introduce un certo stato; questo è il compromesso.

Decodificare un token è la stessa cosa che decifrarlo?

No. La decodifica inverte base64url a JSON: chiunque può farlo, e questo è il punto. La decifratura richiede una chiave e si applica solo a JSON Web Encryption (JWE, RFC 7516), che è la variante crittografata della famiglia JOSE. La maggior parte dei token che vedete in natura sono JWS (firmati ma non crittografati), quindi la decodifica è sufficiente per leggerli.