Gerador de PKCE

Generator

Gere pares PKCE code_verifier e code_challenge para OAuth 2.0 instantaneamente. Conforme RFC 7636, método S256, verifier aleatório URL-safe. Funciona inteiramente no navegador.

Opções
Par PKCE Gerado
Clique em Gerar para criar um par PKCE
O que é PKCE?

PKCE (Proof Key for Code Exchange, pronunciado 'pixie') é uma extensão do OAuth 2.0 (RFC 7636) que protege clientes públicos contra ataques de interceptação de código de autorização. Antes de iniciar o fluxo OAuth, o cliente gera um segredo aleatório chamado code_verifier, deriva um code_challenge dele usando SHA-256 e envia o challenge para o servidor de autorização. Ao trocar o código de autorização por um token, o cliente envia o verifier original — provando que é a mesma entidade que iniciou o fluxo.

PKCE foi originalmente projetado para apps móveis onde segredos de cliente não podem ser mantidos confidenciais, mas agora é recomendado para todos os clientes OAuth 2.0. O RFC 9700 torna o PKCE obrigatório para fluxos de código de autorização. Todos os principais provedores de identidade (Auth0, Okta, Azure AD, Google, GitHub, Keycloak) suportam PKCE.

Como o PKCE Funciona (RFC 7636)
  1. Gere um code_verifier criptograficamente aleatório: 43–128 caracteres URL-safe de [A-Za-z0-9-._~]
  2. Calcule o code_challenge: hash SHA-256 do verifier codificado em UTF-8
  3. Codifique o hash SHA-256 em base64url (sem padding) para obter a string de challenge
  4. Envie code_challenge + code_challenge_method=S256 na requisição de autorização; envie code_verifier na requisição de token
Parâmetros PKCE
ParâmetroValorObservações
code_verifier43–128 chars, URL-safeManter em segredo; gerado novo para cada requisição
code_challengeBASE64URL(SHA-256(verifier))Enviado na requisição de autorização; seguro expor
code_challenge_methodS256Sempre use S256; nunca 'plain'

Sobre esta ferramenta

Sobre o Gerador de PKCE

PKCE (Proof Key for Code Exchange, pronunciado 'pixie') é uma extensão de segurança do OAuth 2.0 definida no RFC 7636. Ela previne ataques de interceptação de código de autorização ao exigir que o cliente prove, no momento da troca de token, que é a mesma entidade que iniciou a requisição de autorização — sem precisar de um segredo de cliente. PKCE é agora obrigatório para todos os clientes OAuth 2.0 públicos (SPAs, apps nativos, apps móveis) conforme as melhores práticas do RFC 9700.

Este gerador usa a Web Crypto API (crypto.getRandomValues + SHA-256) para produzir um code_verifier criptograficamente aleatório com o comprimento escolhido (43–128 caracteres URL-safe), e calcula o code_challenge como BASE64URL(SHA-256(verifier)) usando o método S256. O alfabeto do verifier é restrito a [A-Za-z0-9-._~] conforme o RFC 7636 §4.1. Ambos os valores são calculados inteiramente no navegador.

Use o par gerado no seu fluxo de autorização OAuth 2.0: envie code_challenge e code_challenge_method=S256 na requisição de autorização, armazene code_verifier com segurança na memória ou no sessionStorage, e envie code_verifier na requisição de token. O servidor de autorização recalcula o challenge e confirma que corresponde.

PKCE elimina a necessidade de um segredo de cliente em clientes públicos, tornando seguro implementar OAuth 2.0 em ambientes onde segredos não podem ser mantidos confidenciais (apps de navegador, apps móveis). Toda a geração é feita localmente com a Web Crypto API.

Recursos Principais

  • code_verifier aleatório criptograficamente seguro (43–128 chars)
  • Challenge S256: BASE64URL(SHA-256(verifier))
  • Alfabeto URL-safe conforme RFC 7636
  • Quatro presets de comprimento: 43, 64, 96, 128 chars
  • Cópia individual ou cópia de tudo com um clique
  • Geração automática ao carregar a página
  • 100% baseado no navegador — verifier nunca enviado a nenhum servidor

FAQ

Gerador de PKCE — Perguntas Frequentes

O que é PKCE e por que preciso disso?

PKCE (Proof Key for Code Exchange) é uma extensão de segurança para OAuth 2.0 que previne ataques de interceptação de código de autorização. Sem PKCE, um aplicativo malicioso no mesmo dispositivo poderia interceptar o código de autorização antes do seu aplicativo trocá-lo por um token. Com PKCE, interceptar o código é inútil porque o atacante não tem o code_verifier usado para gerar o code_challenge. PKCE é agora obrigatório para todos os clientes OAuth 2.0 públicos (RFC 9700).

Qual é a diferença entre code_verifier e code_challenge?

O code_verifier é uma string aleatória secreta que seu aplicativo gera antes da requisição de autorização. O code_challenge é um valor derivado calculado como BASE64URL(SHA-256(code_verifier)). Você envia o challenge (não o verifier) para o servidor de autorização primeiro, depois envia o verifier na troca de token. O servidor recalcula o challenge a partir do verifier e confirma que correspondem — provando que você iniciou a requisição.

Qual comprimento devo usar para o code_verifier?

O RFC 7636 permite de 43 a 128 caracteres. O comprimento recomendado é 64 caracteres, o que proporciona 48 bytes de entropia — mais que suficiente. Verifiers mais longos não são significativamente mais seguros dado o challenge SHA-256, mas também não causam problemas. Use sempre pelo menos 43 caracteres.

Por que S256 e não plain?

S256 (SHA-256) é o único método que você deve usar. O método 'plain' envia o code_verifier como challenge — anulando o propósito do PKCE, pois um interceptador que capturar a requisição de autorização já tem o verifier. S256 garante que o verifier nunca seja transmitido antes da troca de token. Alguns servidores ainda suportam 'plain' por compatibilidade, mas você deve sempre solicitar S256.

Onde devo armazenar o code_verifier?

Armazene o code_verifier na memória (uma variável no seu app) durante o fluxo de autorização. Para SPAs com recarregamentos de página entre a requisição de autorização e o callback, o sessionStorage é uma escolha razoável (tem escopo de aba e é limpo ao fechar). Nunca armazene no localStorage por longo prazo ou em um cookie acessível a outras abas.

PKCE funciona com todos os provedores OAuth 2.0?

A maioria dos principais provedores suporta PKCE: Auth0, Okta, Azure AD/Entra ID, Google, GitHub, Keycloak, Cognito e praticamente qualquer servidor compatível com OIDC. Verifique o campo code_challenge_methods_supported no documento de descoberta do provedor para confirmar o suporte.

Dicas

  • Gere um par PKCE novo para cada requisição de autorização — nunca reutilize um verifier
  • O code_verifier deve ser mantido em segredo até a requisição de token; o code_challenge é público
  • Use sessionStorage para persistir o verifier através de recarregamentos de página durante o redirecionamento OAuth
  • Use esta ferramenta para testar sua implementação PKCE verificando manualmente o challenge a partir de um verifier conhecido