search

Found

info Descripción

Genera el code_verifier y el code_challenge S256 de PKCE (RFC 7636) para OAuth 2.0. Elige entre 43 y 128 caracteres y copia los fragmentos de petición /authorize y /token.

📘 Cómo usar

  1. Elige la longitud del verifier entre 43 y 128 caracteres con el deslizador
  2. Pulsa Regenerar para obtener un nuevo code_verifier y su code_challenge S256
  3. Revisa el fragmento de petición para ver dónde encajan los valores en /authorize y /token

Generador de PKCE code_verifier

¡Copiado!
¡Copiado!

        

          
          
¡Copiado!

        

      

    

  




            


            
            

            

            
            

                

                    grid_view Relacionados
                

                
            


        


        
        
    


    
    
    

        
        

            

            Article
            

        


        
        

            
Generador de PKCE code_verifier | Par de prueba para el flujo PKCE OAuth 2.0


Genera un code_verifier y un code_challenge con método S256 válidos según RFC 7636 directamente en tu navegador, con longitudes de 43 a 128 caracteres. La página añade fragmentos de petición listos para /authorize y /token, así puedes pegarlos en Postman, curl o tu cliente SPA, móvil o CLI sin salir de la pestaña.


💡 Sobre esta herramienta


PKCE es la mitigación oficial contra la interceptación del authorization code para clientes públicos OAuth 2.0 (SPAs, apps móviles, CLI nativas y cualquier cliente que no pueda guardar un client secret). El RFC 7636 obliga al cliente a generar un code_verifier con alta entropía (43–128 caracteres del conjunto [A-Z][a-z][0-9]-._~), derivar el code_challenge como base64url(SHA-256(verifier)) y enviar el challenge al /authorize y el verifier original al /token. La matemática es simple, pero hacerla a mano cada vez que se prueba un servidor de autorización es tedioso.


Esta herramienta usa crypto.getRandomValues y crypto.subtle.digest('SHA-256') para producir pares conformes a la especificación cada vez que mueves el deslizador o pulsas Regenerar, con codificación base64url completa (sin padding, +/ reemplazados por -_). El panel inferior reproduce exactamente las peticiones:


GET /authorize?response_type=code&client_id=YOUR_CLIENT_ID&code_challenge=...&code_challenge_method=S256&redirect_uri=...&state=RANDOM_STATE
POST /token (form): grant_type=authorization_code&code=...&code_verifier=...



Así puedes pegar el mismo par en Auth0, Okta, Keycloak, AWS Cognito, Azure AD B2C u otro IdP propio y comprobar que el viaje de ida y vuelta funciona. Todo el cálculo permanece en la pestaña — ningún valor se envía a un servidor — lo que hace seguro usarlo en pruebas de staging, retos CTF y formaciones de seguridad.


🧐 Preguntas Frecuentes


Q. ¿Qué longitud de verifier debo elegir?
A. Cualquier valor entre 43 y 128 caracteres es válido. Las bibliotecas más usadas (Auth0 SPA SDK, MSAL.js, AppAuth) suelen tomar 43–64 caracteres por defecto. Empieza con 64 — si tu servidor de autorización lo acepta, esa longitud te sirve. Bájala a 43 si el volumen de logs te preocupa o súbela a 128 para máxima entropía en informes de auditoría.


Q. ¿Por qué no se ofrece el método plain?
A. RFC 7636 §4.2 marca S256 como MUST-support y plain solo como fallback cuando el cliente no puede calcular SHA-256. Los servidores actuales (Auth0, Okta, Google, Microsoft, GitHub, Spotify, Twitch, X) exigen S256, y el borrador OAuth 2.1 elimina plain por completo. La herramienta nunca emite plain para evitar que cablees un par inseguro en tus pruebas.


Q. ¿Funciona en navegadores antiguos sin SubtleCrypto?
A. crypto.subtle.digest('SHA-256') está disponible en todos los navegadores evergreen (Chrome, Edge, Firefox, Safari) sobre contextos https:// o localhost. La herramienta corre en cualquier entorno de desarrollo moderno, pero fallará silenciosamente en IE 11 o en páginas servidas por http:// fuera de localhost.


Q. ¿Se almacenan los valores generados en algún sitio?
A. No. Cada movimiento del deslizador o pulsación de Regenerar produce un par nuevo, sin persistirlo en localStorage, cookies ni servidor. Trata cada par como desechable — recargar la página los reemplaza.


Q. ¿Qué valor debo poner en state dentro del fragmento?
A. state es tu defensa CSRF — genera un string aleatorio por sesión, guárdalo en el lado servidor o en una cookie segura, y verifica que el callback devuelva el mismo valor. El fragmento deja RANDOM_STATE como marcador porque state es responsabilidad del cliente y no forma parte de PKCE en sí.


📚 Datos Curiosos


PKCE se publicó en 2015 como RFC 7636, originalmente presentado como "extensión para aplicaciones nativas" de OAuth 2.0. El borrador OAuth 2.1 de 2019 lo promovió a "todos los clientes, siempre" y los grandes IdP siguieron el mismo camino: Spotify deprecó Implicit Grant cuando hizo obligatorio PKCE en su Web API en 2021, Twitch hizo lo mismo con la API Helix y X (Twitter) lo volvió obligatorio en su OAuth 2.0 v2 en 2022. El campo code_challenge_method admite teóricamente cualquier valor que el servidor de autorización añada, pero en la práctica solo se estandarizaron S256 y plain — y plain está saliendo del estándar, por lo que un generador moderno solo necesita emitir S256 para cubrir prácticamente toda la web.