Anatomia di un JWT
Un JSON Web Token (RFC 7519) è formato da tre parti codificate in Base64URL unite da punti: header.payload.firma. L’header dice quale algoritmo lo ha firmato. Il payload è un oggetto JSON di claim sul soggetto. La firma copre le prime due parti, così un verificatore può capire se qualcosa è stato alterato.
Le prime due parti sono solo codificate, non cifrate. Chiunque abbia il token può leggere ogni claim, ed è per questo che questo decodificatore funziona senza alcuna chiave, e che un JWT non deve mai contenere segreti.
Claim standard
| Claim | Significato |
|---|---|
| iss | Issuer: chi ha creato il token |
| sub | Subject: di chi parla il token, di solito un ID utente |
| aud | Audience: per quale servizio è destinato il token; i verificatori devono controllarlo |
| exp | Scadenza, come timestamp Unix in secondi |
| nbf | Not before: il token non è valido prima di questo momento |
| iat | Emesso il |
| jti | ID univoco del token, usato per le liste di revoca |
Algoritmi di firma
HS256 (HMAC con SHA-256) usa un unico segreto condiviso sia per firmare sia per verificare, quindi chiunque possa verificare può anche falsificare; va bene per un singolo servizio che parla con se stesso. RS256, ES256 ed EdDSA usano una chiave privata per firmare e una pubblica per verificare, che è ciò che usano gli identity provider (Auth0, Keycloak, Google, Azure AD) perché qualsiasi servizio possa controllare i token senza poterli emettere. Le chiavi pubbliche sono di solito pubblicate a un URL /.well-known/jwks.json.
Cosa devono controllare i verificatori
- La firma, con una chiave adatta all’
algnell’header, e senza mai accettare"alg": "none". - Che
expsia nel futuro enbf, se presente, nel passato (ammettendo un piccolo scostamento degli orologi). - Che
isseaudsiano i valori attesi.
Domande
È sicuro incollare qui il mio token?
Il token viene decodificato da JavaScript nel tuo browser e non viene trasmesso. Ciononostante, un token è una credenziale: trattalo come una password, e preferisci token di prova a breve durata quando fai debug.
Perché il decodificatore dice che il mio token è scaduto?
Il suo claim exp è precedente all’orologio del tuo computer. I token di solito durano poco (da minuti a ore); prendine uno nuovo dall’endpoint di login o di refresh. Se il tuo orologio è sbagliato, anche il controllo lo sarà.
Posso verificare qui un token RS256?
Non in questa versione. RS256 richiede la chiave pubblica dell’emittente (dal suo endpoint JWKS). Il decodificatore mostra header, payload e controlli temporali per qualsiasi algoritmo; solo gli algoritmi HMAC possono essere verificati con un segreto.
Perché il payload è leggibile senza il segreto?
Perché un JWT è firmato, non cifrato. Base64URL è reversibile per progetto. Se il contenuto deve essere nascosto, il token va cifrato come JWE, che sembra simile ma ha cinque parti.
Cosa significa il timestamp in exp?
Secondi dal 1º gennaio 1970 UTC (tempo Unix). Il decodificatore lo converte in una data nel tuo fuso orario e mostra quanto manca. Usa lo strumento del timestamp Unix per convertire altri valori.