# Verificador e challenge de OAuth PKCE

> Gere um code_verifier de OAuth 2.0 e derive seu code_challenge S256, ou cole o seu e verifique-o com as regras de comprimento e de conjunto de caracteres do RFC 7636. A mesma derivação SHA-256 em base64url que o seu servidor de autorização espera. Roda inteiramente no seu navegador.

- Tool: https://ronutz.com/pt-BR/tools/pkce
- Family: Identidade e tokens

---

## O que faz

Trabalhe com os dois valores no centro da extensão PKCE do OAuth 2.0. A ferramenta gera um `code_verifier` aleatório e deriva seu `code_challenge` usando o método S256, ou recebe um `code_verifier` que você cola e o confere com as regras de comprimento e de caracteres da RFC 7636, derivando o mesmo challenge que o seu servidor de autorização vai esperar. A derivação é exatamente o passo de SHA-256 e Base64url definido pelo padrão, e tudo roda no seu navegador.

## Contra o que o PKCE protege

O fluxo de código de autorização do OAuth 2.0 envia um código de curta duração de volta pelo navegador do usuário, e em um aplicativo móvel ou de página única esse redirecionamento pode ser interceptado por outro aplicativo. O PKCE, "Proof Key for Code Exchange", fecha essa brecha. No início do fluxo, o cliente inventa um segredo, o `code_verifier`, e envia apenas uma versão transformada dele, o `code_challenge`, com a requisição inicial. Quando mais tarde troca o código por tokens, ele apresenta o `code_verifier` original, e o servidor re-deriva o challenge e confere se corresponde. Um atacante que roube o código não consegue usá-lo, porque nunca viu o verifier.

## O verifier e o challenge

- O **code_verifier** é uma string aleatória de alta entropia, de 43 a 128 caracteres, extraída do conjunto não reservado `A-Z a-z 0-9 - . _ ~`.
- O **code_challenge** é derivado dele. O método recomendado, `S256`, é `BASE64URL(SHA256(ASCII(verifier)))`, a codificação Base64url do resumo SHA-256 do verifier, sem preenchimento. O método `plain`, em que o challenge simplesmente é igual ao verifier, existe para clientes limitados, mas é desencorajado, porque não oferece proteção se o challenge for observado.

## Por que importa agora

O PKCE começou como uma correção para aplicativos móveis, mas agora é o padrão de base. A prática recomendada de segurança atual do OAuth, a RFC 9700, exige PKCE para todo cliente que usa o fluxo de código de autorização, não apenas os públicos. Se você está construindo ou depurando um cliente OAuth, gerar um verifier e confirmar seu challenge S256 aqui permite conferir sua implementação diretamente contra a especificação.

## Como usar

Gere um `code_verifier` novo e leia seu `code_challenge` `S256`, ou cole um verifier existente para validar seu comprimento e seus caracteres e derivar o challenge correspondente. Como o S256 é um hash unidirecional, o challenge não revela nada sobre o verifier.

## Standards and references

- [RFC 7636 - Proof Key for Code Exchange (PKCE)](https://www.rfc-editor.org/rfc/rfc7636) - verifier, challenge, and S256 derivation
- [RFC 6749 - The OAuth 2.0 Authorization Framework](https://www.rfc-editor.org/rfc/rfc6749) - the authorization-code flow PKCE protects
- [RFC 9700 - Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/rfc/rfc9700) - PKCE required for authorization-code clients

## Related reading

- [Clientes públicos vs confidenciais, e onde o PKCE se encaixa](https://ronutz.com/pt-BR/learn/oauth-client-types.md): Se um cliente OAuth consegue guardar um segredo decide todo o seu modelo de segurança. Por que SPAs e apps móveis são clientes públicos, e por que o PKCE agora é recomendado para todos eles.
- [O fluxo de código de autorização do OAuth 2.0](https://ronutz.com/pt-BR/learn/oauth-code-flow.md): Os quatro papéis, a dança de redirecionar e trocar, e por que o código é trocado por um token no canal de fundo.
- [OpenID Connect: identidade sobre o OAuth 2.0](https://ronutz.com/pt-BR/learn/openid-connect.md): Como o OIDC adiciona autenticação à autorização do OAuth, o que é o token de ID e por que o fluxo de código com PKCE é o caminho recomendado.
- [PKCE: protegendo o fluxo de código de autorização do OAuth](https://ronutz.com/pt-BR/learn/pkce.md): O ataque de interceptação que o PKCE derrota, como o verificador e o desafio se encaixam, e por que o S256 é obrigatório.
- [Tokens de acesso, tokens de atualização e tokens de ID](https://ronutz.com/pt-BR/learn/oauth-tokens.md): Três tokens do OAuth e do OpenID Connect que vivem sendo confundidos, para que cada um de fato serve, e por que enviar o errado ao lugar errado é um bug de verdade.