Perché conta dove viene decodificato un token
Un JWT di produzione è una credenziale viva. Incollarlo in un decodificatore che lo spedisce a un server significa consegnare una sessione valida a terzi, e in molti team succede ogni giorno durante il debug. Questo strumento decodifica con JavaScript nella tua scheda: stacca la rete e continua a funzionare.
Decodificare non è verificare
Lo strumento legge le prime due parti del token e le mostra come JSON. Non controlla la firma, e la distinzione conta: un payload leggibile non significa che il token sia autentico. La verifica richiede la chiave segreta o pubblica dell'emittente, e quel controllo appartiene al tuo backend, non a una pagina web.
I claim che controlli più spesso
`exp` è la scadenza in secondi Unix e spiega la maggior parte dei 401 inattesi. `iat` dice quando è stato emesso. `iss` e `aud` decidono se il token fosse destinato al tuo servizio. Anche `alg` nell'header merita uno sguardo: un token che arriva con `alg: none` è un campanello d'allarme, non una curiosità.
Un JWT non è un posto dove tenere segreti
Tutte e tre le parti sono Base64url, cioè codifica senza chiave. Chi intercetta il token ne legge l'intero contenuto con questo stesso strumento. La firma garantisce che nessuno l'abbia alterato, non che nessuno possa leggerlo. Un valore che il client non deve vedere non va nel payload.