1001Ferramentas
🎟️ Segurança

Gerador de PKCE (code_verifier/challenge)

Gere um par OAuth 2.0 PKCE (code_verifier e code_challenge SHA-256) para fluxos de login seguros em apps móveis e SPAs. Proteja contra interceptação de código.

Carregando…

Como o par PKCE é gerado

App mobile e SPA não têm onde guardar um client_secret, e o código de autorização devolvido no redirect pode ser interceptado por outro app registrado no mesmo esquema de URL. O PKCE resolve isso amarrando o código a um segredo que só o cliente conhece. Esta página gera o par completo: um code_verifier aleatório e o code_challenge SHA-256 correspondente, prontos para um teste de fluxo.

O verifier sai de bytes do crypto.getRandomValues convertidos para base64url. O campo de tamanho é limitado entre 32 e 96 bytes, e isso não é arbitrário: 32 bytes viram exatamente 43 caracteres, o mínimo da RFC 7636, e 96 bytes viram 128, o máximo. O challenge é o base64url do SHA-256 do verifier e sempre sai com 43 caracteres. Um ponto que costuma quebrar implementação caseira: o hash é calculado sobre o texto ASCII do verifier, não sobre os bytes aleatórios originais.

Use o par para testar um fluxo na mão, com curl ou Postman, ou para conferir se a sua implementação produz o mesmo challenge a partir do mesmo verifier. No app de verdade, o verifier precisa nascer dentro do próprio cliente, um novo a cada requisição de autorização, e ser descartado depois da troca pelo token. O método plain existe na especificação, mas só para plataformas sem SHA-256; use S256 sempre. A geração acontece no navegador e nada é enviado.

Perguntas frequentes

Posso usar este verifier no meu app em produção?
Para testar um fluxo manualmente, sim. No app real ele precisa ser gerado pelo próprio cliente a cada login, porque um valor fixo ou reutilizado anula a proteção.
Qual tamanho devo escolher?
Os 32 bytes do padrão já entregam os 43 caracteres mínimos da RFC com entropia de sobra. Subir para 64 ou 96 só aumenta o tamanho da URL de autorização.
O PKCE substitui o client_secret?
Para clientes públicos, sim, e o OAuth 2.1 recomenda PKCE em todo fluxo de authorization code. Clientes confidenciais podem usar segredo e PKCE juntos.

Ferramentas Relacionadas