Decodifichi il payload JWT senza verificare la firma

Restituisce entrambe le sezioni come oggetti strutturati, rendendo semplice esaminare o inoltrare claim, identificatori, timestamp, emittenti, destinatari e metadati dell’algoritmo. La firma non viene deliberatamente verificata: i valori decodificati descrivono ciò che il token dichiara, ma non dimostrano chi lo abbia creato. Usi il risultato per debug, sviluppo, documentazione e ispezioni prudenti, mai come prova che un token sia autentico o autorizzato.

Comprenda cosa dimostra la decodifica e cosa non dimostra

Un JWT contiene normalmente intestazione, payload e firma, uniti da punti. I primi due segmenti sono JSON codificato in base64url: il contenuto è predisposto per un trasporto compatto, ma non è cifrato né nascosto. Questa capacità divide il token fornito, decodifica i due segmenti come UTF-8, analizza il JSON e restituisce gli oggetti di intestazione e payload. Non usa il terzo segmento per autenticare alcunché. La distinzione è fondamentale, perché chiunque può costruire una stringa simile a un token con claim arbitrari. Vedere nel payload decodificato un soggetto, ruolo, emittente, destinatario o valore di scadenza non prova che lo abbia emesso un sistema affidabile. Usi la decodifica quando deve vedere la struttura del token, diagnosticare nomi o valori dei claim oppure ottenere una rappresentazione leggibile durante lo sviluppo. Quando una decisione di sicurezza dipende dal token, usi una libreria di verifica JWT appropriata con una chiave esplicitamente attendibile e vincoli relativi ad algoritmo, emittente e destinatario.

Invii un JWT compatto e interpreti la risposta

Incolli o invii il JWT compatto completo nel campo token. Un token strutturalmente valido presenta esattamente tre segmenti separati da due punti, sebbene questo decodificatore legga solo i primi due. La risposta contiene un oggetto header e un oggetto payload. I campi comuni dell’intestazione includono typ, che spesso identifica il tipo di media JWT, e alg, che indica il presunto algoritmo di firma. Il payload include spesso sub per il soggetto, iss per l’emittente, aud per il destinatario, exp per la scadenza e claim specifici dell’applicazione. Il decodificatore non richiede alcun claim e conserva i valori JSON presenti. I claim NumericDate come exp, nbf e iat restano numeri anziché essere convertiti in date, evitando ipotesi su come Lei intenda visualizzarli o confrontarli. Se il token ha un numero errato di segmenti, base64url malformato, UTF-8 o JSON non valido, oppure una sezione decodificata che non è un oggetto, la richiesta restituisce un errore di input non valido invece di un risultato parziale.

Usi i claim decodificati in modo sicuro

La decodifica è particolarmente utile ai confini tra sistemi. Chi sviluppa un’API può confrontare i claim prodotti da un provider di identità con i nomi attesi dall’applicazione. Il supporto può esaminare un token di prova oscurato per capire se manca un destinatario o uno scope. Una suite di test può decodificare token creati da una fixture locale e verificare che i claim personalizzati necessari siano inclusi, prima di collaudare separatamente la verifica crittografica. Mantenga esplicito il confine di sicurezza in ogni flusso: i dati decodificati sono input non attendibili. Non conceda accesso, non scelga un tenant, non accetti un’identità e non esponga dati privati soltanto perché lo richiede un claim decodificato. Eviti di incollare veri token bearer in log, ticket, chat o documenti condivisi, perché un JWT può essere una credenziale attiva anche se il payload sembra innocuo. Per la diagnosi preferisca esempi sintetici, scaduti o generati localmente. Se un’automazione deve elaborare token reali, li trasmetta soltanto tramite un canale adeguatamente protetto e faccia seguire alla decodifica una verifica basata su configurazioni attendibili.