Decoder JWT
Incollando un JSON Web Token si leggono header e payload come JSON formattato, con le date di scadenza e di emissione mostrate come date leggibili e un'indicazione sulla validità attuale del token. La decodifica avviene interamente nel browser, un aspetto importante quando il token è una credenziale attiva.
0 caratteri · 0 parole · 0 righe
0 caratteri · 0 parole · 0 righe
Funziona interamente in questa scheda del browser. Il testo non viene mai caricato né salvato.
Claim registrati
I sette nomi di claim definiti nella RFC 7519 §4.1. Sono tutti facoltativi; i tempi sono in secondi dal 1970-01-01 UTC.
| Claim | Significato |
|---|---|
iss | Issuer: chi ha creato e firmato il token |
sub | Subject: l'utente o l'entità a cui si riferisce il token |
aud | Audience: il destinatario del token |
exp | Scadenza: rifiutare il token dopo questo momento |
nbf | Non valido prima di: rifiutare il token prima di questo momento |
iat | Emesso il: quando il token è stato creato |
jti | ID JWT: identificatore univoco, usato per prevenire il replay |
Valori alg comuni
| Valore alg | Significato |
|---|---|
HS256 | HMAC con SHA-256; un unico segreto condiviso firma e verifica |
RS256 | Firma RSA PKCS#1 v1.5 con SHA-256; la chiave privata firma, quella pubblica verifica |
PS256 | RSA-PSS con SHA-256 |
ES256 | ECDSA sulla curva P-256 con SHA-256; firme corte |
EdDSA | Firme Ed25519 o Ed448 |
none | Token non firmato; i server dovrebbero rifiutarlo |
Com'è fatto un JSON Web Token
Il JWT è definito nella RFC 7519 (maggio 2015), che suggerisce di pronunciarlo come la parola inglese "jot". La forma firmata più comune è composta da tre stringhe Base64url unite da punti: header.payload.signature. L'header indica in alg l'algoritmo di firma, ad esempio HS256 o RS256, e spesso un ID della chiave in kid. Il payload contiene i claim, campi JSON come sub (l'utente), iss (l'emittente), aud (il destinatario previsto) ed exp, nbf e iat, che sono orari espressi in secondi dal 1° gennaio 1970 UTC. Il decoder converte questi valori nell'ora locale e in ISO 8601, e indica se il token è scaduto, non è ancora valido o si trova nel proprio intervallo di validità.
Base64url è una codifica, non una cifratura: chiunque abbia un token può leggerne il payload esattamente come fa questa pagina. Non inserire mai password, numeri di carta o altri dati segreti nei claim. Un token con cinque parti separate da punti è un JWE, cioè un token cifrato: il suo contenuto non può essere letto senza la chiave, e il decoder lo segnala. Un eventuale "Bearer " iniziale copiato da un'intestazione Authorization viene rimosso automaticamente.
Perché qui la firma non viene verificata
La firma dimostra che header e payload sono stati prodotti da chi possiede la chiave e che non sono stati modificati da allora. Per controllarla serve quella chiave: il segreto condiviso per algoritmi HMAC come HS256, oppure la chiave pubblica dell'emittente per RS256, ES256 o EdDSA. Incollare in una pagina web il segreto di firma di produzione è una cattiva idea, e un decoder che finge di garantire un token senza averlo darebbe una falsa sicurezza: per questo questo strumento mostra la firma ma non la verifica. Ciò che si vede va considerato un'affermazione del token, non un fatto.
La verifica va fatta sul server, con una libreria mantenuta e l'algoritmo atteso fissato. Due errori storici spiegano il motivo: accettare alg "none", che permette a chiunque di falsificare un token non firmato, e la confusione tra algoritmi, in cui un server che si aspetta RS256 viene indotto a controllare una firma HS256 usando la chiave pubblica come segreto HMAC. Un decoder serve per il debug: vedere quali claim emette un provider, individuare un'audience sbagliata o scoprire che una sessione è fallita perché exp è scaduto un minuto fa. Per leggere i segmenti Base64url in forma grezza, usare il decodificatore Base64.
Domande frequenti
- È sicuro incollare un vero token di accesso in un decoder JWT?
- Su questa pagina il token non lascia mai il browser. Tuttavia un token valido funziona come una password fino alla scadenza, quindi conviene usare token scaduti o di prova ed evitare di lasciare quelli attivi in screenshot e chat.
- Perché il token risulta scaduto anche se è appena stato emesso?
- Per prima cosa controllare l'orologio del dispositivo. Alcuni emittenti assegnano agli access token una durata di pochi minuti, e un token copiato da un log può essere più vecchio di quanto sembri. Un exp scritto in millisecondi anziché in secondi produce l'effetto opposto e finisce migliaia di anni nel futuro.
- Qualcuno può modificare il payload di un JWT?
- Può modificarlo e ricodificarlo, ma la firma non corrisponderà più. Un server che verifica le firme con la chiave e l'algoritmo corretti rifiuta il token alterato.
- Qual è la differenza tra JWS e JWE?
- Un JWS (RFC 7515) è firmato, ha tre parti e chiunque può leggerlo. Un JWE (RFC 7516) è cifrato, ha cinque parti e solo chi possiede la chiave può leggerne il payload.
- Il logout invalida un JWT?
- Non da solo. Un JWT firmato resta valido fino a exp, a meno che il server non mantenga una lista di blocco o controlli un registro delle sessioni: per questo agli access token si assegnano di solito durate brevi.