I JWT sono ovunque. Ogni volta che accedi a un’app web, un’API ti emette un JSON Web Token, e quel token porta la tua identità, i tuoi permessi e spesso qualche dettaglio personale nel suo payload. Il formato stesso è stato stabile per un decennio, poi una serie di attività nel 2024-2025 — RFC 8725 (migliori pratiche JWT attuali) è diventato un requisito rigido per le nuove specifiche, il dibattito “i JWT sono male” si è riacceso per il dimensionamento delle sessioni, e diversi grandi provider sono passati ai token opachi per l’uso nel browser. Il risultato: più sviluppatori che mai ispezionano i token manualmente. Quando qualcosa va storto — la tua sessione scade al momento sbagliato, un’API rifiuta un token che pensavi valido, un collega dice “cosa c’è nel JWT?” — la prima cosa che fanno la maggior parte degli sviluppatori è incollare il token in un decodificatore online.
Il problema: la maggior parte di quei decodificatori invia il tuo token a un server. Il token stesso non è un segreto (è solo JSON codificato in base64), ma i contenuti del payload lo sono spesso: un ID utente, un’email, a volte un ID sessione, a volte una lista di permessi. Se il tuo servizio usa i JWT per comunicare con altri servizi interni, il payload potrebbe anche includere nomi di servizi interni o feature flag.
Un token incollato in un decodificatore di terze parti è una piccola perdita di informazioni. La maggior parte delle volte non conta. Ma il principio conta: dovresti poter ispezionare un token senza fidarti dell’infrastruttura di qualcun altro.
Come appare realmente un JWT
Un JWT è tre stringhe codificate in base64url, separate da punti:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cLe tre parti sono header, payload e firma. Decodifica le prime due e ottieni JSON:
// Header
{
"alg": "HS256",
"typ": "JWT"
}// Payload
{
"sub": "12345",
"name": "Alice",
"iat": 1516239022
}La firma è un hash crittografico che dimostra che il token è stato emesso da qualcuno che conosce il segreto. Chiunque può decodificare il payload — questo non è il confine di sicurezza. Il confine di sicurezza è se puoi verificare la firma.
La distinzione tra verifica e decodifica
È qui che molti sviluppati sbagliano. Decodificare non è verificare. Un decodificatore decodifica semplicemente il JSON in base64 in modo che tu possa leggerlo. Chiunque può farlo, e non dimostra che il token è autentico. La verifica è l’atto di controllare la firma contro un segreto noto per confermare che il token non è stato manomesso.
- Per debuggare il contenuto di un token (quali claim ha, quando scade), la decodifica è sufficiente.
- Per autenticare un utente, hai bisogno della verifica, e deve avvenire su un server di cui ti fidi.
La maggior parte degli strumenti decodificatori online solo decodifica. Mostra l’header e il payload ma non chiedono mai il tuo segreto — perché non stanno verificando, ti stanno solo mostrando cosa c’è nel token.
Come decodificare localmente
Non hai bisogno di uno strumento di terze parti per questo. Un JWT è solo tre stringhe base64url. Apri un terminale:
echo 'eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTUxNjIzOTAyMn0' | tr '_-' '/+' | base64 -dQuesto è il payload. L’header è il primo segmento, lo stesso trucco.
Se preferisci non memorizzare la danza tr '_-' '/+', il decodificatore JWT su DevSpeedTools fa la stessa cosa nel browser. Nessuna richiesta di rete, nessun caricamento, nessun log. Apri DevTools → Network, incolla un token e conferma da solo che nulla lascia la tua macchina.
Quando hai davvero bisogno della verifica
Se stai cercando di debuggare un problema di autenticazione e devi sapere se il token è valido (non solo cosa contiene), devi verificare la firma. La verifica deve avvenire con lo stesso segreto o chiave pubblica che usa il tuo server di autenticazione. Questo significa che deve avvenire su un’infrastruttura che controlli.
Alcune opzioni per la verifica che non prevedono incollare il tuo segreto in un sito web:
- In Node.js:
jsonwebtoken.verify(token, process.env.JWT_SECRET). - In Python:
jwt.decode(token, key, algorithms=['HS256']). - In Go:
token, err := jwt.Parse(tokenString, keyFunc). - CLI:
jwt-cli(Rust) opyjwtcon una one-liner.
Se ti trovi davvero a dover usare un verifica online per qualche motivo, cerca uno che dica esplicitamente che funziona nel browser (il sorgente è solitamente visibile). Gli strumenti onesti lo dicono. Gli altri dovresti assumere che caricano il tuo token su un server.
L’errore “invalid signature”
Una ragione comune per cui gli sviluppati finiscono su un decodificatore è l’errore invalid signature. Quel messaggio sta facendo due cose:
- Ti dice che il token è stato firmato con un segreto diverso da quello che stai usando per la verifica.
- Ti dice che il token potrebbe essere stato manomesso.
O — e questa è quella che la maggior parte delle persone perde — il token potrebbe essere scaduto. Controlla il claim exp nel payload. Se il timestamp Unix corrente è oltre exp, il token non è valido. Alcune librerie lanciano invalid signature per token scaduti, il fuorviante.
Il decodificatore JWT mostra il valore exp insieme al resto del payload in modo che tu possa individuare token scaduti a colpo d’occhio. Lo stesso vale per nbf (non prima di), iat (emesso il) e aud (destinatario) — tutti utili per il debug.
In breve
I decodificatori JWT sono utili. Sono anche un posto dove gli sviluppatore diventano casual nell’incollare token di produzione. Un default più sicuro:
- Usa un decodificatore locale o nel browser per ispezioni rapide. Nessun caricamento, nessuna perdita.
- Usa la CLI o il tuo codice per la verifica. Non incollare mai un segreto in un sito web.
- Controlla prima gli standard claim —
expscaduto è la causa della maggior parte dei problemi “il mio token ha smesso improvvisamente di funzionare”.
Il token non è un segreto. I contenuti del token lo sono spesso. Trattalo di conseguenza.