Decodificatore JWT

Dare senso alle claim al suo interno

Una volta decodificato un token, il payload è per lo più una manciata di campi brevi e standardizzati chiamati claim. Quelli che incontrerai costantemente: iss indica l'emittente che ha creato il token, sub identifica l'utente o il soggetto a cui si riferisce, aud indica il pubblico — l'API a cui è destinato — mentre iat registra quando è stato emesso e exp quando smette di essere valido. Qualsiasi altra cosa lì dentro è personalizzata: ruoli, indirizzi email, feature flag, qualunque cosa il sistema emittente abbia deciso di includere. Le claim temporali confondono le persone perché sono semplici timestamp Unix, secondi dal 1970 — un numero come 1784528768 piuttosto che una data leggibile — così l'intera durata di vita del token si nasconde in due modesti interi.

Fare il debug di un token rifiutato

Quando un'API risponde 401 e sei sicuro che il token sia giusto, scorri una breve lista. Primo, se l'hai copiato da un header Authorization, rimuovi la parola Bearer e lo spazio davanti — con quelli attaccati non è un JWT valido e non verrà nemmeno decodificato. Poi, leggi exp e controlla che sia davvero nel futuro: incolla il numero nel convertitore di timestamp Unix e vedrai la scadenza come una data reale, spesso rivelando un token morto ore fa. Poi confronta aud e iss con l'API che stai chiamando — un token coniato per l'ambiente di staging viene regolarmente, e correttamente, rifiutato dalla produzione. E ricorda che un minuto di sfasamento dell'orologio tra i server basta a far sembrare un token appena emesso non ancora valido.

Token che questo strumento non può aprire

Non tutto ciò che protegge un'API è un JWT leggibile. Un token con cinque parti separate da punti invece di tre è un JWE — genuinamente criptato, non semplicemente codificato — e non ne esce nulla di leggibile senza la chiave, qui o altrove. E molti token di sessione sono semplicemente stringhe casuali opache che non sono mai stati JWT fin dall'inizio; se non inizia con qualcosa come eyJ, probabilmente non c'è nulla da decodificare. Per i token che si aprono davvero, aiuta ricordare cosa stai guardando: tre blocchi di testo Base64URL incollati insieme con dei punti. Lo strumento Base64 decodifica qualsiasi singolo blocco da solo, il che è un bel modo per vedere con i tuoi occhi che le parti leggibili di un JWT non sono mai state segrete fin dall'inizio.

Cosa ti dice (e cosa non ti dice) decodificare un JWT

L'header e il payload di un JWT sono solo JSON codificato in Base64URL — chiunque può decodificarli e leggerli, senza bisogno di alcun segreto, ed è esattamente ciò che fa questo strumento. Ciò che non può fare è verificare la firma: serve il segreto o la chiave pubblica dell'emittente, deliberatamente qualcosa che non incolleresti in un sito web qualsiasi.