Testare un flusso OAuth a mano
Costruisci un URL di autorizzazione per Google, Microsoft Entra ID, Okta o Keycloak, accedi nel browser e poi scambia il codice con curl inviando il code_verifier generato.
Sicurezza e privacy
Generatore OAuth PKCE
Crea un code_verifier casuale da 43 a 128 caratteri e il suo code_challenge S256 (RFC 7636), oppure calcola il challenge di un verifier esistente, con uno state casuale e i parametri da aggiungere alla richiesta di autorizzazione.
- Appunti
Lascia vuoto per generarne uno, o incolla un verifier esistente per calcolarne il challenge.
Valori PKCE
Da conservare sul client e inviare quando si scambia il codice con un token.
Base64URL dello SHA-256 del verifier, inviato nella richiesta di autorizzazione.
Valore casuale da verificare al ritorno per bloccare gli attacchi CSRF.
Questo strumento ti è stato utile?
Come funziona questo strumento?
Il generatore OAuth PKCE produce la coppia code_verifier / code_challenge richiesta dal flusso Authorization Code con PKCE, insieme a un parametro state. È pensato per sviluppatori che integrano un login OAuth 2.0 o OpenID Connect in una SPA, un’app mobile o uno strumento da riga di comando, e per chi testa il flusso a mano con curl o Postman.
PKCE (Proof Key for Code Exchange, RFC 7636) protegge il codice di autorizzazione dall’intercettazione. Il client crea un code_verifier segreto da 43 a 128 caratteri presi dall’insieme non riservato A–Z, a–z, 0–9, «-», «.», «_» e «~»; lo strumento ne genera 64 per impostazione predefinita con crypto.getRandomValues. Calcola poi code_challenge = BASE64URL(SHA-256(code_verifier)), senza riempimento. Con l’esempio dell’appendice B della RFC, il verifier dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk produce il challenge E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM.
Il challenge viene inviato nella richiesta di autorizzazione con code_challenge_method=S256 e uno state casuale; il verifier resta al client. Quando scambia il codice con un token, il client invia code_verifier all’endpoint token e il server ricalcola lo SHA-256 per verificare che corrisponda al challenge ricevuto. Un attaccante che intercetta il codice non può quindi riscattarlo senza il verifier. Lo strumento mostra i parametri code_challenge, code_challenge_method e state da aggiungere all’URL di autorizzazione e può anche ricalcolare il challenge di un verifier incollato, per controllare la tua implementazione.
Come usare questo strumento
Genera o incolla un verifier
Scegli una lunghezza da 43 a 128 caratteri (64 predefinita) per generare un code_verifier, oppure incolla un verifier esistente per calcolarne il challenge.
Recupera challenge e state
Copia il code_challenge S256 e lo state casuale, controllando la lunghezza mostrata di verifier e challenge (43 caratteri per uno SHA-256).
Completa la richiesta di autorizzazione
Aggiungi code_challenge, code_challenge_method=S256 e state all’URL di autorizzazione, poi conserva il verifier per inviarlo durante lo scambio del codice.
Casi d’uso
Fare debug di un errore invalid_grant
Il tuo server risponde «PKCE verification failed»: incolla il verifier usato dalla tua app per controllare che il challenge inviato sia davvero lo SHA-256 in Base64URL, senza = né caratteri + e /.
Configurare un client Postman o Insomnia
Genera una coppia verifier / challenge e uno state per compilare a mano un client HTTP che non gestisce PKCE in automatico.
Consigli e buone pratiche
- Genera un nuovo verifier e un nuovo state per ogni tentativo di login: riutilizzare una coppia fissa vanifica PKCE.
- Non usare il metodo plain: la RFC 7636 lo riserva ai client che non possono calcolare SHA-256, situazione che non riguarda nessun browser né piattaforma mobile attuale.
- In una SPA conserva il verifier in sessionStorage per la durata del reindirizzamento anziché nell’archiviazione persistente del browser, ed eliminalo non appena il codice è stato scambiato.
Domande frequenti
Che cos’è PKCE in OAuth?
PKCE (RFC 7636) è un’estensione del flusso Authorization Code: al momento dello scambio del codice, il client dimostra di essere quello che ha avviato la richiesta. Prima invia un code_challenge derivato da un segreto, poi il segreto stesso (code_verifier). Un codice intercettato è inutile senza quel segreto.
Quanto deve essere lungo il code_verifier?
Tra 43 e 128 caratteri, solo tra A–Z, a–z, 0–9 e «- . _ ~». La RFC 7636 consiglia di generarlo da almeno 32 byte casuali, il che dà 43 caratteri in Base64URL. Un valore di 64 caratteri lascia un margine comodo.
Meglio S256 o plain?
S256. Con plain il challenge è uguale al verifier, quindi chiunque veda la richiesta di autorizzazione conosce anche il segreto. I server che supportano PKCE devono accettare S256, e plain esiste solo per casi storici.
Con PKCE serve ancora il parametro state?
La RFC 9700 ammette che PKCE protegge dagli attacchi CSRF quando il server lo applica davvero, ma state resta consigliato per legare la risposta alla sessione dell’utente e trasportare un contesto applicativo. Molti provider lo richiedono ancora. Per questo lo strumento li genera entrambi.
PKCE è obbligatorio per i client confidenziali?
La RFC 9700 (buone pratiche di sicurezza OAuth 2.0, 2025) impone PKCE ai client pubblici e lo raccomanda per quelli confidenziali; la bozza di OAuth 2.1 lo rende obbligatorio per ogni client che usa il codice di autorizzazione. In pratica, attivalo ovunque, anche nelle applicazioni server con client_secret.
Perché il mio code_challenge viene rifiutato?
Gli errori tipici sono un challenge codificato in Base64 standard (con +, / o =) invece che in Base64URL, un hash calcolato su una versione esadecimale dello SHA-256, oppure un verifier diverso tra richiesta di autorizzazione e scambio del codice. Incolla il tuo verifier nello strumento per confrontarlo con il challenge atteso, calcolato localmente senza richieste di rete.
Strumenti correlati
Continua con questi strumenti
Strumenti simili o complementari a questo.
Funziona bene con
Genera token casuali sicuri da 8 a 256 byte in esadecimale, Base64 o Base64URL, con prefisso opzionale.
Sicurezza e privacyNuovoUsa questo strumento
Analizza una chiave JWK o un JWKS: kid, kty, alg, use, impronta RFC 7638 e avviso se una chiave privata è esposta.
Sicurezza e privacyNuovoUsa questo strumento
Verifica la firma di un JWT con un segreto HMAC o una chiave pubblica JWK, JWKS o PEM, poi controlla exp, nbf, iss e aud.
Sicurezza e privacyUsa questo strumento
Leggi anche
GuidaBuone praticheIntermedio
OAuth 2.0, PKCE, JWT, JWK e JWKS: capire i loro ruoli
Comprendi come si collegano OAuth 2.0, PKCE, JWT, JWK e JWKS: autorizzazione, token, chiavi pubbliche e verifica.
23 settembre 20262 min
GuidaBuone praticheIntermedio
Crittografia, hashing e HMAC: capire le differenze
Scopri quando usare crittografia, hashing, HMAC o PBKDF2 per riservatezza, integrità, autenticazione e password.
23 settembre 20262 min
GuidaBuone pratichePrincipiante
Content Security Policy (CSP): ridurre i rischi XSS e i caricamenti indesiderati
Impara a costruire una CSP progressiva, comprenderne le direttive ed evitare policy troppo permissive o che rompono il sito.
29 agosto 20263 min