Vai al contenuto

Verifica con JWKS

JWKS Verifier

Scarica un endpoint JWKS, sceglie la chiave dal kid e verifica la firma di un token e le sue claim standard.

Verifica un token contro il JWKS pubblicato da un emittente — scaricandolo da un URL oppure incollandolo — scegliendo la chiave in base al `kid`, controllando la firma e poi controllando `exp`, `nbf` e, se li si indica, `iss` e `aud`. Il token non viene mai inviato; viene scaricato soltanto l’URL del JWKS.

🔒 Funziona interamente nel tuo browserjwtjwksauthverify

Il token non esce da questa scheda.

Il controllo della firma lo fa il WebCrypto del browser e questa pagina non ha un lato server. L’unica richiesta di rete è una GET all’URL del JWKS che scrivi, e quella richiesta non porta altro che l’URL — non il token.

Token

Il prefisso Bearer viene tolto per te.

Chiavi pubbliche (JWKS)

Origine delle chiavi

Il browser fa una GET diretta. Il token non viene inviato.

Il `jwks_uri` nel /.well-known/openid-configuration dell’emittente è questo indirizzo.

Valori attesi (facoltativo)

Tolleranza di scarto dell’orologio

Lascia vuoto un campo e quel claim non viene controllato. exp e nbf si controllano sempre.

Che cosa viene controllato

  • · RS256/384/512, PS256/384/512, ES256/384/512 e EdDSA (Ed25519) si verificano con WebCrypto (RFC 7518 §3, RFC 8037). HS* usa un segreto condiviso e contro un JWKS non si può proprio controllare: se ne occupa il decodificatore di JWT con il segreto. ES256K e Ed448 non stanno nel WebCrypto di nessun browser.
  • · La chiave si sceglie dal kid nell’header del token (RFC 7515 §4.1.4). Durante una rotazione un JWKS tiene più chiavi, quindi un kid che non combacia viene segnalato come tale.
  • · exp e nbf si controllano con la tolleranza di scarto; iss e aud solo se dai un valore atteso (RFC 7519 §4.1). alg: none viene sempre rifiutato.

Come si usa

  1. Incollare il token

    Il suo `alg`, il suo `kid` e il suo emittente vengono letti subito, ed è questo che dice quale JWKS serve.

  2. Scaricare o incollare il set di chiavi

    Il `/.well-known/openid-configuration` dell’emittente indica il suo `jwks_uri`. Google, Microsoft e Apple hanno pulsanti di scorciatoia; tutto il resto si digita o si incolla.

  3. Compilare quello che ci si aspetta

    Un `iss` e un `aud` lasciati vuoti non vengono controllati per niente — ed è così che nei sistemi veri viene accettato un token destinato a un altro destinatario. La tolleranza sullo scarto degli orologi copre i server che non vanno d’accordo per un minuto.

  4. Leggere il verdetto e la tabella dei claim

    Il banner dice se accettare o non accettare; la tabella sotto dice quale controllo ha prodotto quella risposta e quale chiave è stata scelta.

Domande frequenti

Lo scaricamento è fallito con un errore CORS.

Un endpoint JWKS deve mandare le intestazioni CORS perché un browser possa leggerlo. Google, Microsoft e Apple lo fanno; molti emittenti self-hosted no. Basta scaricarlo da sé con curl e incollare il JSON: la verifica è identica in entrambi i casi.

Dice che nessuna chiave corrisponde al kid.

Di solito è una rotazione delle chiavi: il token è stato firmato prima che l’emittente ruotasse, e ora il JWKS contiene solo le chiavi più recenti. Può anche voler dire che il token viene da un emittente diverso da quello del JWKS scaricato.

Perché `alg: none` viene sempre rifiutato?

Perché accettarlo è la classica vulnerabilità dei JWT: chi attacca riscrive l’intestazione, toglie la firma, e una libreria che si fida dell’intestazione lascia passare il token. In un percorso di verifica non ne esiste nessun uso legittimo.

Può controllare un token HS256?

Non qui: HS* è un segreto condiviso e un JWKS pubblica chiavi pubbliche. Va usato il decodificatore di JWT, che accetta un segreto. Un emittente che pubblicasse chiavi HMAC in un JWKS pubblicherebbe la capacità di coniare token.

Può ricevere da

Dopo

Questi accettano ciò che produce questo strumento, così il risultato può passare direttamente.