¿Odias los anuncios? Ir Sin publicidad Hoy 

Generador de código PKCE de verificador y desafío

DesarrolladorSeguridad

APORTE

Configuración de PKCE

Longitud del verificador: 64 El RFC 7636 requiere entre 43 y 128 caracteres. Valores más largos proporcionan más entropía.

Método de desafío

S256 es requerido por OAuth 2.1 y es compatible con todos los proveedores modernos.

Codificación del verificador

Ambas generan verificadores compatibles con el RFC 7636. Elige la que espera tu biblioteca de cliente.

PROD.

Lado cliente

ANUNCIO · ¿ELIMINAR?

Guía

Generador de verificador y desafío de PKCE

Generador de código PKCE de verificador y desafío

Genera valores compatibles con el RFC 7636 de PKCE directamente en tu navegador. Elige una longitud del verificador (43–128 caracteres), y la herramienta produce un valor aleatorio criptográficamente seguro code_verifier junto con el SHA-256 correspondiente code_challenge en formato base64url, listo para insertar en cualquier solicitud de autorización de OAuth 2.0 o OAuth 2.1. Útil para aplicaciones web, aplicaciones móviles, interfaces de línea de comandos nativas y cualquier persona que esté depurando un flujo de autorización con código y PKCE contra proveedores como Auth0, Okta, Microsoft Entra, Google, GitHub y Keycloak.

Cómo Usar

Arrastra el Longitud del verificador controlador de deslizamiento — cualquier valor entre 43 y 128 funciona; valores más largos proporcionan más entropía.
Elige el Método de desafío. Deja encendido S256 a menos que tu proveedor requiera explícitamente plain.
Elige un Codificación del verificador. Ambas opciones son compatibles con el RFC; el alfabeto base64url coincide con lo que emiten la mayoría de las bibliotecas de clientes de OAuth.
Haz clic en Generar. El verificador, el desafío y el método aparecen inmediatamente, junto con una explicación paso a paso de la transformación de SHA-256 → base64url.
Copia el code_challenge + code_challenge_method a tu /authorize redirección, almacena el code_verifier en sessionStorage, y repítelo en /token para finalizar el intercambio.

Características

Aleatoriedad criptográficamente segura – utiliza crypto.getRandomValues() con muestreo de rechazo para evitar el sesgo de módulo en el alfabeto de 66 caracteres no reservados.
SHA-256 nativa — el desafío se calcula mediante el navegador’s SubtleCrypto.digest('SHA-256'), por lo que los valores coinciden con lo que producirá tu servidor de autorización.
Métodos S256 y plain — ambos code_challenge_method valores definidos en el RFC 7636 están soportados, con S256 seleccionado por defecto según OAuth 2.1.
Desglose paso a paso — ve el verificador crudo, el resumen hexadecimal de 32 bytes de SHA-256 y el desafío final en base64url para auditar cada transformación.
Dos opciones de alfabeto — elige el conjunto completo de caracteres no reservados del RFC 7636 (A–Z, a–z, 0–9, -, ., _, ~) o el alfabeto más estrecho de base64url que usan por defecto la mayoría de las bibliotecas.
Rango de longitud del deslizador, 43 a 128 — permanece dentro del estándar sin tener que manejar números mágicos.
Copia con un clic en cada campo de salida para que puedas pegar directamente en Postman, curl o en tu código de cliente.
100% del lado del cliente — nada se envía a un servidor. El verificador nunca abandona tu pestaña del navegador.

 Preguntas frecuentes

¿Qué es PKCE y por qué necesita OAuth?

Clave de prueba para el intercambio de códigos (PKCE, RFC 7636) es una extensión de OAuth 2.0 que protege el flujo de códigos de autorización contra la interceptación. El cliente elige un secreto code_verifier, deriva un code_challenge a partir de él, y envía solo el desafío en la solicitud de autorización. Cuando el cliente posteriormente intercambia el código de autorización en el punto de token, envía el verificador original; el servidor lo hash y lo compara con el desafío almacenado. Incluso si un atacante intercepta el código de autorización, no puede intercambiarlo sin el verificador, que nunca abandona al cliente legítimo. OAuth 2.1 hace que PKCE sea obligatorio para todos los clientes, tanto públicos como confidenciales.
¿Cuánto debe ser el código_verifier y por qué?

El RFC 7636 requiere que el verificador tenga entre 43 y 128 caracteres del conjunto no reservado. El límite inferior existe porque 43 caracteres en base64url equivalen a 32 bytes aleatorios (256 bits), el mínimo de entropía considerado seguro contra ataques por fuerza bruta. Verificadores más largos proporcionan más entropía, pero no ofrecen beneficios reales de seguridad pastas los 256 bits. La mayoría de las implementaciones de referencia eligen 43, 64 o 128. Elige el extremo más largo si deseas una defensa en profundidad, pero ten en cuenta que algunos servidores legados rechazan cualquier valor por encima de 128 porque aplican estrictamente el estándar.
¿Cuál es la diferencia entre los métodos de desafío S256 y plain?

, la cookie se envía a S256 el desafío es la hash SHA-256 del verificador, codificada en base64url; con plain el desafío es el verificador en sí. El plain método no ofrece protección real si la solicitud de autorización es interceptada — un atacante que ve el desafío ya tiene el verificador. El RFC 7636 solo permite plain para clientes que realmente no pueden calcular SHA-256, y OAuth 2.1 lo prohibe por completo. Los proveedores de identidad de producción como Auth0, Okta, Google y Microsoft Entra rechazan plain directamente, así que siempre utiliza S256 a menos que estés depurando un cliente embebido con restricciones.
¿Qué es base64url y cómo se diferencia de base64?

base64url es una variante URL segura de base64 definida en el RFC 4648 §5. Reemplaza + con - y / con _ así que la cadena codificada es segura para insertar en un parámetro de consulta, un segmento de JWT o un componente de ruta sin necesidad de escapado adicional. El relleno final = también se elimina porque la longitud se implica por el contexto circundante. PKCE, JWT, JWE, JWS y la mayoría de las especificaciones de criptografía web modernas usan base64url por estas razones.