Generador de code challenge PKCE
Crea un code_verifier PKCE aleatorio criptográficamente seguro y su code_challenge S256 con la Web Crypto API, tal como especifica la RFC 7636. Arma una URL de autorización y una solicitud de token listas para probar, o comprueba si un verifier y un challenge existentes forman pareja.
Última actualización:
Generador de URL de autorización y solicitud de token
Verificar un par
Cómo usar Generador de code challenge PKCE
- Haz clic en Generar nuevo par (hay un par listo al cargar la página). Ajusta la longitud del verifier si hace falta.
- Copia el code_challenge y envíalo con
code_challenge_method=S256en la solicitud de autorización, o usa el generador de URL. - Guarda el code_verifier de forma segura en tu app (en memoria o en el almacenamiento de sesión) hasta que el usuario vuelva con un código de autorización.
- Intercambia el código: envía el code_verifier en la solicitud de token (mira el ejemplo con curl).
- ¿Depurando? Pega un verifier y un challenge en Verificar un par para ver si coinciden.
Cómo funciona el flujo PKCE
- Crear el verifier. El cliente genera un
code_verifieraleatorio de alta entropía (43-128 caracteres deA-Z a-z 0-9 - . _ ~) y lo mantiene en secreto. - Derivar el challenge.
code_challenge = BASE64URL(SHA256(code_verifier)), en Base64URL sin relleno=. - Solicitud de autorización. El cliente redirige al usuario al servidor de autorización con
code_challengeycode_challenge_method=S256. El servidor guarda el challenge junto con el código de autorización que emite. - Solicitud de token. El cliente envía el código de autorización junto con el
code_verifieroriginal. - Comprobación. El servidor calcula el hash del verifier y lo compara con el challenge guardado. Solo el cliente que inició el flujo puede completarlo.
Vector de prueba de la RFC 7636 (Apéndice B)
| code_verifier | dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk |
|---|---|
| code_challenge (S256) | E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM |
Haz clic en Cargar ejemplo de la RFC 7636 para reproducirlo con esta herramienta. Si tu propio código da un resultado distinto, los culpables habituales son usar Base64 estándar en lugar de Base64URL, dejar el relleno =, calcular el hash del string hexadecimal del resumen o calcular el hash de un string con un salto de línea final.
Generar PKCE en código
JavaScript (navegador o Node 18+):
const b64url = b => btoa(String.fromCharCode(...new Uint8Array(b)))
.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
const verifier = b64url(crypto.getRandomValues(new Uint8Array(32)));
const challenge = b64url(await crypto.subtle.digest('SHA-256',
new TextEncoder().encode(verifier)));
Python:
import base64, hashlib, secrets
verifier = secrets.token_urlsafe(32) # 43 characters
challenge = base64.urlsafe_b64encode(
hashlib.sha256(verifier.encode('ascii')).digest()).rstrip(b'=').decode()
Preguntas frecuentes
¿Qué es PKCE?
PKCE (Proof Key for Code Exchange, que se pronuncia "pixy") es una extensión de OAuth 2.0 definida en la RFC 7636. El cliente crea un code_verifier secreto, envía solo su hash (el code_challenge) con la solicitud de autorización y después demuestra que inició el flujo enviando el verifier con la solicitud de token. Un atacante que intercepte el código de autorización no puede usarlo sin el verifier.
¿Cómo se calcula el code challenge S256?
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))). El resumen SHA-256 de los bytes ASCII del verifier se codifica en Base64URL: + pasa a ser -, / pasa a ser _ y se elimina el relleno = final. Por eso un challenge SHA-256 siempre tiene 43 caracteres.
¿Qué reglas debe cumplir un code_verifier?
Debe tener de 43 a 128 caracteres y usar solo los caracteres no reservados A-Z, a-z, 0-9, guion, punto, guion bajo y virgulilla. La RFC 7636 recomienda generar 32 bytes aleatorios y codificarlos en Base64URL, lo que da un verifier de 43 caracteres con 256 bits de entropía.
¿Debo usar S256 o plain?
Usa siempre S256 cuando el cliente pueda calcular SHA-256, algo que puede hacer cualquier plataforma moderna. Con plain, el challenge es igual al verifier, así que cualquiera que vea la solicitud de autorización también conoce el verifier. OAuth 2.1 y muchos proveedores exigen S256.
¿Sigo necesitando un parámetro state con PKCE?
PKCE protege contra la interceptación del código de autorización y también evita CSRF cuando el servidor lo exige, pero muchos proveedores y bibliotecas siguen esperando un valor state, que además es útil para transportar contexto de la app. La recomendación habitual es usar ambos.
¿PKCE es solo para apps móviles y de una sola página?
No. PKCE se diseñó para clientes públicos, como apps móviles y de navegador que no pueden guardar un secreto de cliente, pero la OAuth 2.0 Security Best Current Practice (RFC 9700) también lo recomienda para clientes confidenciales del lado del servidor, y OAuth 2.1 lo hace obligatorio en el flujo de código de autorización.
¿Es seguro generar un code_verifier en un sitio web?
Esta página crea los valores localmente con el generador aleatorio criptográfico del navegador y nunca los transmite. Aun así, en producción tu aplicación debe generar un verifier nuevo en cada inicio de sesión; usa esta herramienta para aprender, probar y depurar.
¿Se prueban todas las herramientas de FreeToolCabin para comprobar su calidad y precisión?
Sí. Cada herramienta del sitio pasa pruebas automáticas en navegadores reales para comprobar que el resultado es correcto y que no hay errores. Si encuentras un fallo o tienes una sugerencia, escríbenos a [email protected] y lo revisaremos.