Decodificatore JWT

Decodifica un JSON Web Token per leggerne header e payload.

100% privato — funziona interamente nel tuo browser. I tuoi dati vengono elaborati sul tuo dispositivo e non vengono mai inviati a Internet.

Header
Payload

Informazioni sul decodificatore JWT

Questo decodificatore JWT gratuito legge un JSON Web Token e ne mostra l'intestazione e il payload come JSON formattato, con gli orari di emissione e di scadenza convertiti in date leggibili.

La decodifica avviene nel suo browser — il suo token non viene mai caricato. Non è un dettaglio da poco: un JWT è di solito una credenziale attiva, e incollarne uno in un sito che lo invia da qualche parte significa cedere tutti gli accessi che contiene.

Questo strumento decodifica un token. Non verifica la firma — più avanti spieghiamo perché questa distinzione è importante.

Le tre parti di un token

Un JWT è composto da tre blocchi di Base64url separati da punti:

xxxxx.yyyyy.zzzzz

Intestazione — quale algoritmo ha firmato il token e di che tipo è. Di solito due campi: alg e typ.

Payload — le dichiarazioni (claim). Chi riguarda il token, chi lo ha emesso, quando scade e tutto ciò che l'applicazione vi ha inserito: ID utente, e-mail, ruoli, permessi, tenant.

Firma — un controllo crittografico sulle prime due parti, prodotto con un segreto o una chiave privata. Dimostra che il token non è stato modificato dopo l'emissione.

La cosa essenziale da capire: le prime due parti non sono cifrate. Sono soltanto codificate, e chiunque può leggerle. Incolli un token in questa pagina e il suo contenuto compare all'istante. Base64url è un modo per rendere i dati trasportabili in un URL o in un'intestazione, non un modo per nasconderli.

Cosa significa per ciò che inserisce in un token

Poiché il payload è pubblico per chiunque possieda il token, la regola ne discende direttamente: non metta mai nulla di segreto in un JWT.

Cosa non deve stare in un payload: password, chiavi API, dati di carte di credito, numeri di documenti di identità, informazioni mediche, tutto ciò che rientra nella normativa sulla privacy. Tutto questo è leggibile dall'utente, da qualunque sistema registri la richiesta e da chiunque ottenga il token.

Cosa invece ci sta bene: un ID utente, un ruolo, una scadenza, un emittente, un destinatario — identificatori e dichiarazioni destinati a essere visti dal sistema che li riceve.

La firma protegge l'integrità, non la riservatezza. Garantisce che nessuno abbia modificato il token. Non impedisce affatto di leggerlo.

Decodificare non è verificare

È la distinzione che causa veri e propri bug di sicurezza, quindi vale la pena essere precisi.

Decodificare apre il Base64url e le mostra il JSON. Non richiede alcuna chiave, chiunque può farlo e non prova assolutamente nulla sull'autenticità del token.

Verificare ricalcola la firma usando il segreto o la chiave pubblica e controlla che corrisponda. Solo questo le dice che il token è stato davvero emesso da chi dichiara e che non è stato manomesso.

Un token può decodificarsi perfettamente ed essere un falso completo. Chiunque può costruire un JWT che dica "role": "admin" e qui verrà visualizzato benissimo — perché visualizzarlo è tutto ciò che sta accadendo.

Questo strumento deliberatamente non verifica, ed è la scelta sicura: la verifica richiede il segreto di firma, e incollare il suo segreto di firma in una pagina web sarebbe molto più pericoloso che incollarvi un token. La verifica appartiene al suo server, con la sua chiave, usando una libreria adeguata.

La versione storica di questo errore è l'attacco alg: none. Le prime librerie JWT rispettavano un'intestazione che dichiarava di non aver usato alcun algoritmo e accettavano il token senza verifica. Un attaccante poteva modificare il payload, impostare alg su none ed entrare. Le librerie moderne lo rifiutano, ma è il motivo per cui conviene sempre fissare l'algoritmo atteso invece di fidarsi dell'intestazione.

Leggere le dichiarazioni standard

La maggior parte dei nomi di campo brevi in un payload sono claim registrati con significati fissi:

  • exp — orario di scadenza. Dopo questo momento il token va rifiutato.
  • iat — issued at, emesso il. Quando è stato creato.
  • nbf — not before, non prima di. Il token non è valido fino a quel momento.
  • sub — soggetto. Di solito l'ID utente.
  • iss — emittente. Chi ha creato il token.
  • aud — destinatario. A quale servizio è destinato.
  • jti — ID del token, usato per le liste di revoca.

exp, iat e nbf sono timestamp Unix — secondi dal 1° gennaio 1970 — ed è per questo che sembrano un numero di dieci cifre privo di senso. Questo strumento li converte in date leggibili, che di solito è il modo più rapido per rispondere alla domanda che l'ha portata qui: *questo token è scaduto?*

Come usarlo

  • Incolli il suo JWT (la stringa xxxxx.yyyyy.zzzzz)
  • Legga l'intestazione e il payload decodificati qui sotto
  • Copi una delle due parti se le serve

Buono a sapersi

  • Tratti un token come una password. Se è ancora valido, chiunque lo possieda può agire come quell'utente. Non incolli token attivi in strumenti che li caricano e non li pubblichi in un ticket o in una chat.
  • I JWT sono difficili da revocare. Sono validi fino alla scadenza, quindi un token rubato funziona fino ad allora se non si mantiene una lista di blocco. Ecco perché contano le scadenze brevi.
  • Bearer non fa parte del token. Rimuova quel prefisso da un'intestazione Authorization prima di decodificare.
  • Base64url non è il Base64 standard. Usa - e _ al posto di + e / e di solito elimina il riempimento =, motivo per cui un blocco di JWT può fallire in un normale decodificatore Base64.
  • Lo sfasamento degli orologi causa errori sconcertanti. Un token può sembrarle valido ed essere rifiutato da un server il cui orologio differisce di un minuto o due.
  • Un JWT non è una sessione. Porta con sé le proprie dichiarazioni, quindi le modifiche al ruolo di un utente non hanno effetto finché il token non scade.

Domande frequenti

Un JWT è cifrato?

No. L'intestazione e il payload sono codificati in Base64url, il che li rende trasportabili in un URL o in un'intestazione HTTP ma non li nasconde affatto. Chiunque possieda il token può leggere ogni dichiarazione al suo interno, come dimostra questa pagina. La firma protegge il token dalla modifica, non dalla lettura.

Questo strumento verifica la firma?

No, e di proposito. La verifica richiede il segreto di firma o la chiave pubblica, e incollare il suo segreto di firma in una pagina web sarebbe assai più pericoloso che incollarvi un token. La verifica appartiene al suo server, con una libreria adeguata. Questo strumento decodifica e le mostra il contenuto, che è ciò che serve durante il debug.

È sicuro incollare qui il mio token?

Qui sì — la decodifica avviene interamente nel suo browser e non viene trasmesso nulla, quindi può scollegarsi da internet e funziona lo stesso. In generale, però, faccia attenzione con gli strumenti online. Un JWT attivo è una credenziale funzionante, e un sito che lo invia a un server ha appena ricevuto tutti gli accessi che esso concede.

Come capisco se il mio token è scaduto?

Guardi la dichiarazione exp, che è un timestamp Unix in secondi. Questo strumento la converte in una data leggibile e le dice direttamente se quel momento è passato. Se un token le sembra valido ma un server lo rifiuta, controlli lo sfasamento degli orologi — basta una differenza di un minuto o due tra le macchine.

Cosa significano sub, iss, aud e iat?

Sono claim registrati con significati standard: sub è il soggetto, normalmente l'ID utente; iss è l'emittente che ha creato il token; aud è il destinatario previsto, cioè quale servizio dovrebbe accettarlo; iat è il momento dell'emissione. Insieme a exp e nbf coprono il chi, il dove e il quando.

Perché il mio JWT fallisce in un normale decodificatore Base64?

Perché un JWT usa Base64url, una variante che sostituisce + con - e / con _ e di solito rimuove il riempimento =. Queste sostituzioni esistono perché il valore sia sicuro all'interno di un URL. Riportando indietro i caratteri, si decodifica in uno strumento Base64 standard.

Posso modificare il payload di un JWT?

Può cambiarne il testo, ma il risultato verrà rifiutato da qualunque server implementato correttamente, perché la firma non corrisponde più al contenuto modificato. È esattamente a questo che serve la firma. I token vengono riemessi dal servizio che li firma, non modificati a mano.

Strumenti correlati

Video tutorial

Aggiungiamo regolarmente nuovi strumenti — iscriviti su YouTube per ricevere una notifica a ogni novità.

Altri strumenti

Vedi tutti

App consigliate

Vedi tutti