Decodificatore JWT

I JSON Web Token (JWT) sono un modo compatto e URL-safe per rappresentare claim tra due parti. La maggior parte dei JWT sono firmati usando JWS (JSON Web Signature), che garantisce l'integrita ma non crittografa i contenuti. Questo strumento decodifica l'header e il payload per rivelare i claim, visualizza i timestamp in formato leggibile e mostra lo stato di scadenza del token.

Specifiche

Casi d'uso comuni

Debug dei flussi di autenticazione OAuth 2.0 e OpenID Connect
Ispezione di access token e ID token dai provider di identita (Auth0, Okta, Keycloak)
Verifica che i claim del token corrispondano ai valori attesi durante lo sviluppo API
Controllo della scadenza del token nella risoluzione degli errori "401 Unauthorized"
Comprensione della struttura del token durante l'integrazione con servizi di terze parti
Audit dei token per la revisione di sicurezza (algoritmo, claim, scadenza)

Funzionalità

Decodifica di header e payload JWT (formato JWS)
Visualizzazione dell'algoritmo (HS256, RS256, ES256, PS256, EdDSA) e del tipo di token
Analisi dei claim registrati: iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), jti (JWT ID)
Visualizzazione dello stato di scadenza con conto alla rovescia leggibile
Copia delle sezioni decodificate come JSON formattato

Esempi

Access Token OAuth 2.0

Provalo →

Un tipico access token con claim standard inclusi subject, issuer e scadenza.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE5MTYyMzkwMjJ9.4S5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5

Suggerimenti

I token JWS (il tipo piu comune) sono firmati ma non crittografati. Chiunque abbia il token puo leggere il payload decodificandolo in Base64.
I token JWE crittografano il payload, ma sono meno comuni. Questo strumento decodifica i token JWS.
Verifica sempre le firme lato server prima di fidarti dei claim. Questo strumento mostra il contenuto decodificato ma non verifica le firme.
L'algoritmo "alg": "none" e un rischio di sicurezza e dovrebbe essere rifiutato dai server.
Gli algoritmi simmetrici (HS256) usano un segreto condiviso; gli algoritmi asimmetrici (RS256, ES256) usano coppie di chiavi pubblica/privata.
Il claim "exp" e un timestamp Unix in secondi. Controllalo per evitare di accettare token scaduti.

Approfondimenti Decodificatore JWT

I JSON Web Token (JWT) sono il formato di token dominante per l'autenticazione e l'autorizzazione web moderna. Un JWT e una stringa compatta e URL-safe composta da tre segmenti codificati in Base64url separati da punti: un header che specifica l'algoritmo di firma, un payload contenente claim sull'utente o la sessione, e una firma crittografica che garantisce che il token non sia stato manomesso. Questa struttura consente a qualsiasi parte di leggere i contenuti del token tramite semplice decodifica Base64, mentre solo le parti con la chiave di firma possono creare o verificare token validi.

La maggior parte dei JWT usa il formato JWS (JSON Web Signature), dove il payload e firmato ma non crittografato. Il campo "alg" dell'header specifica l'algoritmo: algoritmi simmetrici come HS256 usano un segreto condiviso noto sia all'emittente che al verificatore, mentre algoritmi asimmetrici come RS256 e ES256 usano una chiave privata per la firma e una chiave pubblica per la verifica. Gli algoritmi asimmetrici sono preferiti nei sistemi distribuiti perche la chiave di verifica puo essere condivisa pubblicamente senza compromettere la chiave di firma.

Il payload contiene claim registrati definiti dall'RFC 7519: "iss" (issuer), "sub" (subject), "aud" (audience), "exp" (expiration time), "nbf" (not before), "iat" (issued at) e "jti" (JWT ID). OAuth 2.0 e OpenID Connect aggiungono claim supplementari per scope, ruoli e informazioni del profilo utente. Il claim "exp" e critico per la sicurezza: i token senza scadenza o con durate eccessivamente lunghe sono una vulnerabilita comune.

I JWT sono usati negli access token OAuth 2.0, negli ID token OpenID Connect, nell'autenticazione API e nella gestione delle sessioni. I provider di identita come Auth0, Okta e Keycloak emettono JWT che le applicazioni verificano senza contattare il provider, abilitando l'autenticazione stateless. Tuttavia, questo significa anche che la revoca e difficile: un token compromesso rimane valido fino alla scadenza, motivo per cui tempi di scadenza brevi e flussi di refresh del token sono pratiche di sicurezza essenziali.

Poiche i token JWS sono codificati in Base64url piuttosto che crittografati, chiunque possieda il token puo decodificare e leggere l'header e il payload. Informazioni sensibili come password, numeri di carte di credito e segreti non dovrebbero mai essere inseriti nel payload di un JWT. I token JWE (JSON Web Encryption) crittografano effettivamente il payload, ma sono molto meno comuni nella pratica. La distinzione tra codifica e crittografia e una delle cose piu importanti da comprendere quando si lavora con i JWT.

La scelta dell'algoritmo di firma ha implicazioni di sicurezza significative. HS256 e un algoritmo simmetrico che usa un singolo segreto condiviso sia per la firma che per la verifica, rendendolo semplice da implementare ma richiedendo che entrambe le parti archivino in modo sicuro lo stesso segreto. RS256 e ES256 sono algoritmi asimmetrici che usano una chiave privata per la firma e una chiave pubblica per la verifica. Nei sistemi distribuiti, gli algoritmi asimmetrici sono preferiti perche la chiave pubblica puo essere condivisa apertamente, spesso attraverso un endpoint JWKS (JSON Web Key Set), senza compromettere la chiave di firma. L'opzione "alg": "none" segnala un token non firmato senza alcuna firma, il che significa che chiunque puo falsificare token con claim arbitrari. Un attacco ben noto prevede il cambio dell'header dell'algoritmo a "none" e la rimozione della firma. I server dovrebbero sempre validare l'algoritmo contro una lista consentita e rifiutare i token non firmati.

La corretta gestione della scadenza e essenziale per la sicurezza JWT. Le applicazioni dovrebbero controllare il claim "exp" a ogni richiesta prima di fidarsi del token. Quando un token scade, un refresh token (archiviato in modo sicuro, spesso in un cookie httpOnly) puo essere usato per ottenere un nuovo access token senza richiedere all'utente di accedere nuovamente. Mantenere le durate degli access token brevi, tipicamente da 5 a 15 minuti, limita la finestra di esposizione se un token viene compromesso. L'implementazione proattiva del refresh del token, prima che l'access token scada effettivamente, evita interruzioni visibili all'utente nell'applicazione.

← Torna a tutti gli strumenti