Anúncios incomodam? Ir Sem anúncios Hoje 

Gerador de Código PKCE e Desafio

DesenvolvedorSegurança

ANUNCIADO Remover?

ENTRADA

Configuração PKCE

Comprimento do Verificador: 64 O RFC 7636 exige entre 43 e 128 caracteres. Valores mais longos fornecem mais entropia.

Método de Desafio

O S256 é exigido pelo OAuth 2.1 e é suportado por todos os provedores modernos.

Conjunto de Caracteres do Verificador

Ambas produzem verificadores compatíveis com o RFC 7636. Escolha a opção esperada pela sua biblioteca de cliente.

SAÍDA

Lado cliente

ANUNCIADO Remover?

Guia

Gerador de Código PKCE e Desafio

Gere valores compatíveis com o RFC 7636 do PKCE diretamente no seu navegador. Escolha um comprimento do verificador (43–128 caracteres) e a ferramenta produzirá um valor aleatório criptograficamente seguro code_verifier juntamente com a correspondente SHA-256 code_challenge na forma base64url, pronta para ser inserida em qualquer solicitação de autorização do OAuth 2.0 ou OAuth 2.1. Útil para SPAs, aplicativos móveis, CLIs nativos e qualquer pessoa que esteja debugando um fluxo de autorização com código e PKCE contra provedores como Auth0, Okta, Microsoft Entra, Google, GitHub e Keycloak.

Como usar

Arraste o Comprimento do Verificador slide — qualquer valor entre 43 e 128 funciona; valores mais longos fornecem mais entropia.
Escolha o Método de Desafio. Deixe-o ligado S256 a menos que o seu provedor exija explicitamente plain.
Escolha um Conjunto de Caracteres do Verificador. Ambas as opções são compatíveis com o RFC; o alfabeto base64url corresponde ao que a maioria das bibliotecas de cliente emite.
Clique Gere. O verificador, o desafio e o método aparecem instantaneamente, juntamente com uma explicação passo a passo da transformação SHA-256 → base64url.
Copie o code_challenge + code_challenge_method para o seu /authorize redirecionamento, armazene o code_verifier em sessionStoragee repita-o em /token para concluir a troca.

Características

Aleatoriedade criptograficamente segura – usa crypto.getRandomValues() com amostragem de rejeição, para garantir que não haja viés de módulo no alfabeto de 66 caracteres não reservados.
SHA-256 nativa – o desafio é calculado pelo navegador SubtleCrypto.digest('SHA-256'), portanto os valores correspondem aos que seu servidor de autorização produzirá.
Métodos S256 e plain – ambos code_challenge_method valores do RFC 7636 são suportados, com S256 selecionado por padrão conforme o OAuth 2.1.
Explicação passo a passo – veja o verificador bruto, o digest hexadecimal de 32 bytes SHA-256 e o desafio final em base64url para auditar cada transformação.
Duas opções de conjunto de caracteres – escolha o conjunto completo do RFC 7636 não reservado (A–Z, a–z, 0–9, -, ., _, ~) ou o alfabeto mais restrito base64url que a maioria das bibliotecas usa como padrão.
Escala de comprimento, de 43 a 128 – permaneça dentro do especificado sem lidar com números mágicos.
Cópia com um clique em todos os campos de saída para que você possa colar diretamente em Postman, curl ou no seu código de cliente.
100% do lado do cliente – nada é enviado para um servidor. O verificador nunca sai da sua aba do navegador.

 Perguntas frequentes

O que é PKCE e por que o OAuth precisa disso?

Proof Key for Code Exchange (PKCE, RFC 7636) é uma extensão do OAuth 2.0 que protege o fluxo de código de autorização contra interceptação. O cliente escolhe um segredo code_verifier, deriva um code_challenge a partir dele e envia apenas o desafio na solicitação de autorização. Quando o cliente, posteriormente, recompensa o código de autorização no ponto de terminação de tokens, envia o verificador original; o servidor o hasha e o compara com o desafio armazenado. Mesmo que um atacante intercepte o código de autorização, não poderá usá-lo sem o verificador, que nunca sai do cliente legítimo. O OAuth 2.1 torna o PKCE obrigatório para todos os clientes, tanto públicos quanto confidenciais.
Qual deve ser o comprimento do code_verifier e por que?

O RFC 7636 exige que o verificador tenha entre 43 e 128 caracteres do conjunto não reservado. A fronteira inferior existe porque 43 caracteres base64url codificam 32 bytes aleatórios (256 bits) — o mínimo de entropia considerado seguro contra força bruta. Verificadores mais longos fornecem mais entropia, mas não oferecem benefício real de segurança além de 256 bits. A maioria das implementações de referência escolhe 43, 64 ou 128. Escolha o limite superior se deseja uma defesa em profundidade, mas tenha consciência de que alguns servidores antigos rejeitam qualquer valor acima de 128 porque aplicam rigorosamente a especificação.
Qual é a diferença entre os métodos de desafio S256 e plain?

Com S256 o desafio é a hash SHA-256 do verificador, codificada em base64url; com plain o desafio é o verificador em si. O plain não oferece proteção real se a solicitação de autorização for interceptada — um atacante que vê o desafio já possui o verificador. O RFC 7636 permite apenas plain para clientes que realmente não conseguem calcular SHA-256, e o OAuth 2.1 o proíbe totalmente. Provedores de identidade de produção como Auth0, Okta, Google e Microsoft Entra rejeitam plain de forma explícita, portanto sempre use S256 a menos que você esteja debugando um cliente embarcado com restrições.
O que é base64url e como difere da base64?

A base64url é uma variante URL-safra da base64 definida no RFC 4648 §5. Substitui + com - e / com _ para que a string codificada seja segura para ser inserida em um parâmetro de consulta, segmento JWT ou componente de caminho sem necessidade de escapação adicional. O preenchimento final = também é removido porque o comprimento é implicitamente indicado pelo contexto circundante. Especificações modernas de PKCE, JWT, JWE, JWS e criptografia web usam base64url por essas razões exatas.