search

Found

info Visão geral

Gera o code_verifier PKCE e o code_challenge S256 (RFC 7636) para OAuth 2.0. Escolha entre 43 e 128 caracteres e copie os trechos de requisição /authorize e /token.

📘 Como usar

  1. Escolha o tamanho do verifier entre 43 e 128 caracteres com o controle deslizante
  2. Clique em Regenerar para obter um novo code_verifier e seu code_challenge S256
  3. Confira o trecho de requisição para ver onde encaixar cada valor em /authorize e /token

Gerador de code_verifier PKCE

Copiado!
Copiado!

        

          
          
Copiado!

        

      

    

  




            


            
            

            

            
            

                

                    grid_view Relacionados
                

                
            


        


        
        
    


    
    
    

        
        

            

            Article
            

        


        
        

            
Gerador de code_verifier PKCE | Par de testes para o fluxo PKCE OAuth 2.0


Gere um code_verifier e um code_challenge no método S256 conforme a RFC 7636 direto no seu navegador, com comprimentos de 43 a 128 caracteres. A página também produz trechos prontos para /authorize e /token, prontos para colar no Postman, no curl ou no seu cliente SPA, mobile ou CLI sem sair da aba.


💡 Sobre esta ferramenta


PKCE é a mitigação oficial contra a interceptação do authorization code para clientes OAuth 2.0 públicos — SPAs, apps mobile, CLIs nativas e qualquer cliente que não consiga guardar um client secret. A RFC 7636 obriga o cliente a gerar um code_verifier de alta entropia (43–128 caracteres do conjunto [A-Z][a-z][0-9]-._~), derivar o code_challenge como base64url(SHA-256(verifier)) e enviar o challenge ao /authorize e o verifier original ao /token. A matemática é simples, mas refazê-la manualmente a cada teste de servidor de autorização cansa rápido.


A ferramenta usa crypto.getRandomValues e crypto.subtle.digest('SHA-256') para produzir um par conforme a cada movimento do controle ou clique em Regenerar, com codificação base64url completa (sem padding, +/ substituídos por -_). O painel inferior reproduz exatamente as requisições:


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=...



Assim você pode validar contra Auth0, Okta, Keycloak, AWS Cognito, Azure AD B2C, o gov.br (OIDC) ou qualquer IdP próprio. Nenhum valor sai da aba, então é seguro usar em staging, em desafios CTF e em treinamentos de segurança.


🧐 Perguntas frequentes


Q. Que tamanho de verifier devo escolher?
A. Qualquer valor entre 43 e 128 caracteres é válido. Bibliotecas usuais (Auth0 SPA SDK, MSAL.js, AppAuth, oidc-client-ts) adotam 43–64 caracteres por padrão. Comece em 64 — se o servidor de autorização aceitar, o tamanho está bom. Reduza para 43 se o volume de logs importa, ou suba para 128 quando quiser entropia máxima em relatórios de auditoria.


Q. Por que o método plain não é oferecido?
A. A RFC 7636 §4.2 marca S256 como MUST-support e plain apenas como fallback quando o cliente não pode calcular SHA-256. Em 2026 os principais servidores (Auth0, Okta, Google, Microsoft, GitHub, Spotify, Twitch, X) exigem S256, e o rascunho OAuth 2.1 remove plain por completo. A ferramenta nunca emite plain para evitar conectar um par inseguro nos seus testes.


Q. Funciona em navegadores antigos sem SubtleCrypto?
A. crypto.subtle.digest('SHA-256') está disponível em todos os navegadores evergreen (Chrome, Edge, Firefox, Safari) sobre contextos https:// ou localhost. A ferramenta roda em qualquer ambiente de desenvolvimento moderno, mas falhará silenciosamente em IE 11 ou em páginas servidas por http:// fora de localhost.


Q. Os valores gerados ficam armazenados em algum lugar?
A. Não. Cada movimento do controle ou clique em Regenerar produz um par novo, sem persistir em localStorage, cookies ou servidor. Trate cada par como descartável — recarregar a página substitui o par.


Q. O que devo colocar no parâmetro state do trecho?
A. state é sua proteção CSRF — gere uma string aleatória por sessão, guarde-a no lado servidor ou em um cookie seguro, e verifique se o callback devolve o mesmo valor. O trecho deixa RANDOM_STATE como placeholder porque state é responsabilidade do cliente e não faz parte do PKCE em si.


📚 Curiosidades


PKCE foi publicado em 2015 como RFC 7636, inicialmente como "extensão para aplicações nativas" do OAuth 2.0. O rascunho OAuth 2.1 de 2019 promoveu o mecanismo a "todos os clientes, sempre" e os grandes IdPs seguiram a mesma direção: o Spotify deprecou o Implicit Grant quando passou a exigir PKCE na Web API em 2021, o Twitch fez o mesmo com a API Helix, e o X (Twitter) tornou-o obrigatório no OAuth 2.0 v2 em 2022. O campo code_challenge_method admite teoricamente qualquer valor adicionado pelo servidor de autorização, mas na prática só S256 e plain foram padronizados — e plain está saindo do padrão. Um gerador moderno só precisa emitir S256 para cobrir praticamente toda a web.