Decoder JWT

Tre pezzi di testo uniti da punti

Una volta che hai effettuato l’accesso a un sito web, il server deve riconoscerti di nuovo alla richiesta successiva. Un modo comune per farlo è consegnare al tuo browser un breve biglietto firmato che dice «questo è l’utente 48213, autorizzato a leggere gli ordini, fino alle 15:15». Quel biglietto è un JSON Web Token, o JWT.

Un JWT sembra una lunga stringa casuale, ma ha sempre la stessa forma, header.payload.signature.

• L’header è un piccolo oggetto JSON che indica l’algoritmo di firma (alg) e spesso la chiave usata (kid).
• Il payload è un oggetto JSON di claim, cioè affermazioni come sub (chi), aud (per quale servizio) e exp (fino a quando).
• La firma è un sigillo calcolato a partire dai primi due pezzi e da una chiave.

Header e payload sono scritti in Base64URL, un modo di scrivere byte con lettere, cifre, - e _ perché sopravvivano al passaggio in un indirizzo o in un header HTTP. È anche per questo che quasi ogni token comincia con eyJ: è così che esce {" in quella codifica.

Codificato non vuol dire cifrato

Base64URL è un modo di scrivere. Non chiude niente a chiave, e riportarlo in testo non richiede alcuna chiave: è tutto quello che fa questa pagina. Quindi un JWT firmato non nasconde proprio nulla. Se il payload contiene un indirizzo e-mail, un ruolo o un ID interno, chiunque metta le mani sul token può leggerlo, che sia un’estensione del browser, il log di un proxy o uno screenshot.

Quello che la firma ti dà è l’integrità. Cambia un solo carattere del payload e il sigillo non corrisponde più, quindi il server rifiuta il token. Le persone possono ancora leggerlo. Semplicemente non possono riscriverlo.

Cosa legge questa pagina e cosa segnala

Il decoder toglie un eventuale Bearer iniziale, gli spazi e gli a capo, divide il token e stampa header e payload come JSON formattato. Poi passa in rassegna i claim uno per uno. Le tre date, exp, nbf (non prima di) e iat (emesso il), sono numeri di secondi dal 1° gennaio 1970. Le vedi nel tuo fuso orario e in UTC, con un conto alla rovescia in tempo reale come «valido per altri 12 minuti».

Ricevi anche una parola sull’algoritmo. HS256 usa un unico segreto condiviso per firmare e per verificare. RS256, ES256 ed EdDSA usano una coppia di chiavi, in cui una chiave privata firma e una chiave pubblica verifica, quindi i servizi che si limitano a verificare i token non possono crearne.

Cosa la decodifica non può dirti

Questa pagina non verifica la firma. Servirebbe il segreto o la chiave pubblica dell’emittente, e una pagina che ti chiede il segreto di firma è una pagina da chiudere. Di conseguenza, qui un token falsificato e uno autentico sembrano uguali. Leggi il risultato come «questo è ciò che il token afferma», mai come «questo token è valido».

Per lo stesso motivo, «non scaduto» significa solo che exp è successivo all’orologio del tuo dispositivo. Il server potrebbe aver revocato il token un’ora fa.

Se stai scrivendo il lato che riceve, i controlli che contano avvengono nel tuo codice. Accetta solo gli algoritmi che ti aspetti, verifica la firma con una chiave di cui ti fidi già, poi confronta iss, aud ed exp con quello che ti aspetti. Usa una libreria mantenuta e non scegliere mai il percorso in base all’alg che il token richiede.

Un token attivo è una credenziale

Finché non scade, un bearer token funziona per chiunque lo presenti. Incolla un token di produzione in un sito web e l’hai consegnato a quel sito, a meno che la decodifica non avvenga nel tuo browser. Qui è così. Nessuna richiesta trasporta il token, non viene scritto nella barra degli indirizzi e non viene salvato nella memoria del browser. Non devi crederci sulla parola: guarda la scheda Rete degli strumenti per sviluppatori, oppure carica la pagina e vai offline prima di incollare.

Anche così, l’abitudine più sicura è fare debug con token di un account di prova o con token scaduti. Se un token vero finisce in una chat, un ticket o un log pubblico, esci da tutte le sessioni o chiedi all’emittente di revocarlo.