Probar un flujo OAuth a mano
Construye una URL de autorización para Google, Microsoft Entra ID, Okta o Keycloak, inicia sesión en el navegador y canjea el código con curl enviando el code_verifier generado.
Seguridad y privacidad
Generador OAuth PKCE
Crea un code_verifier aleatorio de 43 a 128 caracteres y su code_challenge S256 (RFC 7636), o calcula el challenge de un verifier existente, con un state aleatorio y los parámetros que debes añadir a la petición de autorización.
- Portapapeles
Déjalo vacío para generar uno, o pega un verifier existente para calcular su challenge.
Valores PKCE
Guárdalo en el cliente y envíalo al canjear el código por un token.
Base64URL del SHA-256 del verifier, enviado en la solicitud de autorización.
Valor aleatorio que comprobar a la vuelta para bloquear ataques CSRF.
¿Te ha resultado útil esta herramienta?
¿Cómo funciona esta herramienta?
El generador OAuth PKCE produce el par code_verifier / code_challenge que exige el flujo Authorization Code con PKCE, junto con un parámetro state. Está pensado para desarrolladores que integran un inicio de sesión OAuth 2.0 u OpenID Connect en una SPA, una app móvil o una herramienta de línea de comandos, y para quien prueba el flujo a mano con curl o Postman.
PKCE (Proof Key for Code Exchange, RFC 7636) protege el código de autorización contra la interceptación. El cliente crea un code_verifier secreto de 43 a 128 caracteres del conjunto no reservado A–Z, a–z, 0–9, «-», «.», «_» y «~»; la herramienta genera 64 por defecto con crypto.getRandomValues. Después calcula code_challenge = BASE64URL(SHA-256(code_verifier)), sin relleno. Con el ejemplo del anexo B de la RFC, el verifier dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk da el challenge E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM.
El challenge viaja en la petición de autorización con code_challenge_method=S256 y un state aleatorio; el verifier se queda en el cliente. Al canjear el código por un token, el cliente envía code_verifier al endpoint token y el servidor recalcula el SHA-256 para comprobar que coincide con el challenge recibido. Así, un atacante que intercepte el código no puede canjearlo sin el verifier. La herramienta muestra los parámetros code_challenge, code_challenge_method y state que debes añadir a la URL de autorización, y también puede recalcular el challenge de un verifier que pegues para comprobar tu propia implementación.
Cómo utilizar esta herramienta
Genera o pega un verifier
Elige una longitud de 43 a 128 caracteres (64 por defecto) para generar un code_verifier, o pega un verifier existente para calcular su challenge.
Obtén el challenge y el state
Copia el code_challenge S256 y el state aleatorio, comprobando la longitud mostrada del verifier y del challenge (43 caracteres para un SHA-256).
Completa la petición de autorización
Añade code_challenge, code_challenge_method=S256 y state a la URL de autorización y guarda el verifier para enviarlo al canjear el código.
Casos de uso
Depurar un error invalid_grant
Tu servidor responde «PKCE verification failed»: pega el verifier que usó tu aplicación para comprobar que el challenge que envía es de verdad el SHA-256 en Base64URL, sin = ni caracteres + y /.
Configurar un cliente Postman o Insomnia
Genera un par verifier / challenge y un state para rellenar a mano un cliente HTTP que no gestiona PKCE automáticamente.
Consejos y buenas prácticas
- Genera un verifier y un state nuevos en cada intento de inicio de sesión: reutilizar un par fijo anula la utilidad de PKCE.
- No uses el método plain: la RFC 7636 lo reserva a clientes que no pueden calcular SHA-256, algo que hoy no le ocurre a ningún navegador ni plataforma móvil.
- En una SPA, guarda el verifier en sessionStorage mientras dura la redirección en lugar de en el almacenamiento persistente del navegador, y bórralo en cuanto se haya canjeado el código.
Preguntas frecuentes
¿Qué es PKCE en OAuth?
PKCE (RFC 7636) es una extensión del flujo Authorization Code: al canjear el código, el cliente demuestra que es quien inició la petición. Primero envía un code_challenge derivado de un secreto y después el propio secreto (code_verifier). Un código interceptado no sirve de nada sin ese secreto.
¿Qué longitud debe tener el code_verifier?
Entre 43 y 128 caracteres, solo con A–Z, a–z, 0–9 y «- . _ ~». La RFC 7636 recomienda generarlo a partir de al menos 32 bytes aleatorios, lo que da 43 caracteres en Base64URL. Un valor de 64 caracteres deja un margen cómodo.
¿Debo usar S256 o plain?
S256. Con plain, el challenge es igual al verifier, así que cualquiera que vea la petición de autorización conoce también el secreto. Los servidores que admiten PKCE deben aceptar S256, y plain solo existe para casos heredados.
¿Sigue haciendo falta el parámetro state con PKCE?
La RFC 9700 admite que PKCE protege contra CSRF cuando el servidor lo aplica de verdad, pero state sigue siendo recomendable para vincular la respuesta a la sesión del usuario y transportar contexto de la aplicación. Muchos proveedores todavía lo exigen. Por eso la herramienta genera ambos.
¿PKCE es obligatorio para clientes confidenciales?
La RFC 9700 (buenas prácticas de seguridad de OAuth 2.0, 2025) exige PKCE a los clientes públicos y lo recomienda para los confidenciales; el borrador de OAuth 2.1 lo hace obligatorio para todo cliente que use el código de autorización. En la práctica, actívalo siempre, también en aplicaciones de servidor con client_secret.
¿Por qué rechazan mi code_challenge?
Los errores típicos son un challenge codificado en Base64 estándar (con +, / o =) en lugar de Base64URL, un hash calculado sobre una versión hexadecimal del SHA-256, o un verifier distinto entre la petición de autorización y el canje del código. Pega tu verifier en la herramienta para compararlo con el challenge esperado, calculado localmente sin ninguna petición de red.
Herramientas relacionadas
Continúa con estas herramientas
Herramientas similares o complementarias a esta.
Funciona bien con
Genera tokens aleatorios seguros de 8 a 256 bytes en hexadecimal, Base64 o Base64URL, con prefijo opcional.
Seguridad y privacidadNuevaUsar esta herramienta
Analiza una clave JWK o un JWKS: kid, kty, alg, use, huella RFC 7638 y aviso si se expone una clave privada.
Seguridad y privacidadNuevaUsar esta herramienta
Verifica la firma de un JWT con un secreto HMAC o una clave pública JWK, JWKS o PEM, y comprueba exp, nbf, iss y aud.
Seguridad y privacidadUsar esta herramienta
También te puede interesar
GuíaBuenas prácticasIntermedio
OAuth 2.0, PKCE, JWT, JWK y JWKS: entender sus funciones
Comprende cómo encajan OAuth 2.0, PKCE, JWT, JWK y JWKS: autorización, tokens, claves públicas y verificación.
23 de septiembre de 20262 min
GuíaBuenas prácticasPrincipiante
Content Security Policy (CSP): reducir riesgos XSS y cargas no deseadas
Aprende a implantar una CSP de forma progresiva, sus directivas principales, Report-Only, nonces y errores frecuentes.
29 de agosto de 20261 min