Vai al contenuto principale
Bethemesh
Sicurezza e privacy

Verificatore di firma JWT

Valida un JSON Web Token: firma HS256/384/512 con il segreto condiviso, RS, PS o ES 256/384/512 con una chiave pubblica JWK, JWKS (scelta tramite kid) o PEM, poi controllo delle date con tolleranza dell’orologio, dell’emittente e dell’audience attesi.

  • Appunti

Integra questo widget

Personalizza il risultato, controlla l’anteprima e copia il codice.

Anteprima

Tipo di codice di integrazione

Codice da copiare

Responsive e ridimensionato automaticamente da Bethemesh.

HS256, HS384, HS512: il segreto condiviso. RS, PS ed ES: la chiave pubblica in JWK, JWKS (scelta tramite kid) o PEM «BEGIN PUBLIC KEY».

Controlli facoltativi

Imposta l’algoritmo per una validazione simile alla produzione. La modalità automatica serve soprattutto per l’ispezione.

Questo strumento ti è stato utile?

Come funziona questo strumento?

Il verificatore JWT ti dice se un token è autentico e ancora accettabile: controlla la sua firma crittografica e poi i claim. È pensato per sviluppatori back-end, integratori OAuth/OpenID Connect e team di sicurezza che vogliono confermare che un token sia stato firmato dalla chiave giusta prima di cercare il bug altrove. Per leggere soltanto il contenuto di un token basta il decoder JWT.

La firma di un JWS (RFC 7515) è calcolata sulla stringa «header.payload» in Base64URL; gli algoritmi sono definiti dalla RFC 7518. Per HS256, HS384 e HS512 lo strumento ricalcola un HMAC con il segreto condiviso e lo confronta con la firma. Per RS256/384/512 (RSASSA-PKCS1-v1_5), PS256/384/512 (RSASSA-PSS) ed ES256/384/512 (ECDSA su P-256, P-384 e P-521) verifica la firma con la chiave pubblica tramite la Web Crypto API; in ECDSA la firma JWS è la concatenazione diretta R‖S, 64 byte per ES256, non una struttura DER. Un token che dichiara alg: none viene sempre rifiutato.

La chiave pubblica può essere fornita in tre forme: una singola JWK (RFC 7517), un JWKS {"keys":[…]} in cui lo strumento sceglie la chiave il cui kid corrisponde a quello dell’header, oppure un PEM «BEGIN PUBLIC KEY» (SubjectPublicKeyInfo). Per una verifica simile a quella di produzione, seleziona un Algoritmo atteso invece di lasciare la modalità Automatica: così il token non può imporre un altro algoritmo supportato tramite il proprio campo alg. La modalità Automatica resta utile per l’ispezione. Una volta validata la firma, controlla exp e nbf con una tolleranza dell’orologio regolabile (ad esempio 60 secondi per assorbire lo scarto tra server) e, se li indichi, l’emittente iss e l’audience aud attesi. Il risultato indica «valido» o «non valido» con il motivo preciso: firma errata, kid non trovato, token scaduto, non ancora valido, emittente o audience inattesi.

Come usare questo strumento

  1. Incolla il JWT

    Incolla il token completo. L’algoritmo dichiarato nell’header determina il tipo di chiave atteso: un segreto per HS*, una chiave pubblica per RS*, PS* ed ES*.

  2. Fornisci la chiave

    Inserisci il segreto condiviso oppure incolla una chiave pubblica JWK, un intero JWKS o un PEM PUBLIC KEY. Con un JWKS la chiave viene scelta automaticamente grazie al kid.

  3. Imposta i controlli e leggi l’esito

    Regola la tolleranza dell’orologio, aggiungi se serve l’emittente e l’audience attesi, poi leggi il risultato valido o non valido con il relativo motivo.

Casi d’uso

Verificare un token Auth0, Keycloak o Entra ID

Recupera il JWKS pubblicato al jwks_uri del tuo provider (ad esempio /.well-known/jwks.json), incollalo con il token e conferma che la firma RS256 corrisponda a una chiave pubblicata.

Fare debug di una rotazione delle chiavi

Dopo una rotazione la tua API rifiuta dei token: controlla se il kid dell’header esiste ancora nel JWKS o se il token è stato firmato con una chiave ritirata.

Controllare un segreto HS256 tra due servizi

Un microservizio rifiuta i token emessi da un altro: prova il segreto condiviso e l’audience attesa per capire se il problema è la chiave o i claim.

Esempi

Ispeziona un JWT di prova

Input

Token JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c; Algoritmo atteso: HS256; Segreto o chiave pubblica: chiave-errata

Risultato

Token rifiutato: Firma non valida: il token è stato modificato o la chiave non corrisponde. Dati del token: sub=1234567890 e iat=1516239022, senza il campo exp.

Consigli e buone pratiche

  • Se hai solo un certificato (BEGIN CERTIFICATE), estrai prima la sua chiave pubblica, ad esempio con openssl x509 -pubkey -noout, perché lo strumento si aspetta un PEM PUBLIC KEY.
  • Un segreto HS256 fornito in Base64 da un provider va usato con esattamente gli stessi byte impiegati per firmare: la stringa Base64 e la sua versione decodificata non producono la stessa firma.
  • Mantieni breve la tolleranza dell’orologio (da qualche decina di secondi a pochi minuti): un valore troppo ampio equivale ad accettare token scaduti.

Fonti e riferimenti

Domande frequenti

Che differenza c’è tra decodificare e verificare un JWT?

Decodificare significa leggere header e payload codificati in Base64URL, senza alcuna chiave. Verificare significa ricalcolare o controllare la firma con il segreto o la chiave pubblica dell’emittente, poi validare exp, nbf, iss e aud. Solo la verifica dimostra che il token non è stato falsificato né modificato.

Quale chiave serve per verificare un JWT RS256 o HS256?

HS256 è simmetrico: lo stesso segreto firma e verifica. RS256, PS256 ed ES256 sono asimmetrici: l’emittente firma con la sua chiave privata e tu verifichi con la chiave pubblica, di solito pubblicata in un JWKS. Per verificare non ti serve mai la chiave privata.

A cosa serve il kid nell’header di un JWT?

Il kid (key ID) indica quale chiave del JWKS ha firmato il token, così l’emittente può pubblicare più chiavi durante una rotazione. Quando incolli un JWKS, lo strumento seleziona la chiave con il kid corrispondente. Se nessun kid corrisponde, la chiave è probabilmente stata ritirata o il JWKS non proviene dall’emittente giusto.

Perché la firma del mio JWT non è valida?

Le cause più comuni sono una chiave sbagliata (altro ambiente, chiave ritirata), un segreto codificato male, un token modificato o troncato, oppure una chiave che non corrisponde all’algoritmo dichiarato. Sul server imponi sempre l’algoritmo atteso invece di fidarti del campo alg, per evitare gli attacchi di confusione dell’algoritmo descritti nella RFC 8725.

Che cos’è la tolleranza dell’orologio (leeway)?

È un margine aggiunto nel controllo di exp e nbf per compensare una piccola differenza tra l’orologio dell’emittente e quello del verificatore. Con 60 secondi di tolleranza, un token scaduto da 30 secondi viene ancora accettato. La maggior parte delle librerie usa un valore tra 0 e 5 minuti.

Posso incollare una chiave o un segreto in questo strumento?

Una chiave pubblica non è segreta e puoi incollarla senza rischi. Un segreto HMAC invece lo è: qui la verifica avviene nel tuo browser con la Web Crypto API e nulla viene trasmesso, ma evita comunque di usare un segreto di produzione su un computer condiviso.

Flusso di lavoro consigliato

Continua l’elaborazione

Scopri gli strumenti che si integrano naturalmente prima, dopo o insieme a questo.

Da usare prima

Decoder JWT

Decodifica un JWT per leggere header, payload, claim e date di scadenza.

Sicurezza e privacyIn evidenzaUsa questo strumento

Funziona bene con

Ispettore JWK / JWKS

Analizza una chiave JWK o un JWKS: kid, kty, alg, use, impronta RFC 7638 e avviso se una chiave privata è esposta.

Sicurezza e privacyUsa questo strumento

Encoder JWT

Crea e firma un JWT HS256, HS384 o HS512 a partire da un header, un payload JSON e un segreto.

Sicurezza e privacyUsa questo strumento

Leggi anche