PKCE: Protegendo Clientes Públicos

Sem PKCE, os aplicativos móveis ficam vulneráveis a ataques de interceptação do código de autorização. Quando o servidor de autorização redireciona o código de autorização para o esquema de URI personalizado registrado pelo aplicativo, como myapp://callback, qualquer aplicativo malicioso no mesmo dispositivo que registre o mesmo esquema de URI pode interceptar o redirecionamento e roubar o código.

O ataque ocorre da seguinte forma: um aplicativo malicioso registra o mesmo esquema de URI personalizado que o aplicativo legítimo. Quando o servidor de autorização redireciona o código para myapp://callback, o OS pode apresentar os dois aplicativos como responsáveis pelo atendimento. Se o usuário selecionar o aplicativo malicioso ou o OS usá-lo como padrão, o invasor receberá o código de autorização e poderá trocá-lo por tokens sem conhecer o segredo do cliente.

O PKCE (RFC 7636) adiciona um segredo gerado dinamicamente ao fluxo do código de autorização. Antes de iniciar o fluxo, o cliente gera uma sequência de caracteres criptograficamente aleatória, com 43 a 128 caracteres, chamada verificador do código. Essa sequência é exclusiva de cada solicitação de autorização e nunca é transmitida até a etapa de troca do token.

O cliente calcula um desafio do código a partir do verificador: code_challenge = BASE64URL(SHA256(code_verifier)). Usar SHA256 é o método exigido pelo RFC 7636; o método "plain", que envia o verificador diretamente, não é recomendado. O desafio do código é uma transformação unidirecional do verificador, o que significa que conhecer o desafio não revela o verificador.

A solicitação de autorização inclui dois parâmetros adicionais: "code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256". O servidor de autorização armazena o desafio do código associado ao código de autorização emitido. Nenhum segredo que pudesse ser interceptado nessa etapa é transmitido ao servidor.

Durante a troca do token (POST para o ponto de acesso de tokens), o cliente inclui "code_verifier=ORIGINAL_RANDOM_STRING" junto com o código de autorização. O servidor de autorização calcula BASE64URL(SHA256(code_verifier)) e verifica se o resultado corresponde ao code_challenge armazenado. Somente o cliente legítimo que gerou o verificador pode passar nessa verificação.

Se um invasor interceptar o código de autorização, receberá apenas o código e o desafio do código, que é público. Para trocar o código por tokens, ele precisará fornecer o verificador do código. Como o verificador foi gerado pelo cliente legítimo e nunca foi transmitido até a troca do token, que ocorre com segurança, o invasor não pode calculá-lo nem obtê-lo.

O PKCE também impede ataques de injeção do código de autorização, nos quais um atacante substitui um código válido por um código roubado no redirecionamento. O desafio do código roubado não corresponde ao verificador que o cliente da vítima apresentará, fazendo a troca de tokens falhar. O PKCE oferece defesa em profundidade contra vários vetores de ataque simultaneamente.

Embora a RFC 7636 tenha sido inicialmente descrita como uma solução para clientes públicos (aqueles sem segredos de cliente), o BCP de Segurança do OAuth e o OAuth 2.1 exigem PKCE para todos os clientes, incluindo clientes confidenciais com segredos de cliente. O PKCE oferece proteção independente da autenticação do cliente, tornando-o universalmente benéfico.

O OAuth 2.1 (draft-ietf-oauth-v2-1) consolida as melhores práticas de segurança do BCP de Segurança do OAuth em um único documento. Ele exige PKCE para todos os fluxos de código de autorização, torna obsoleto o fluxo implícito e exige a rotação de tokens de atualização. O PKCE é, na prática, o padrão mínimo obrigatório para qualquer nova implementação do OAuth 2.0.

Implementar o PKCE corretamente exige: usar um gerador aleatório criptograficamente seguro para o verificador (pelo menos 32 bytes aleatórios, codificados posteriormente em base64url), armazenar o verificador com segurança no cliente (não na URL nem nos registros), usar o método S256 (não plain) e garantir que o verificador seja descartado após a troca de tokens. A maioria das bibliotecas OAuth modernas gerencia o PKCE automaticamente.

No PKCE, qual é a relação entre o verificador de código e o desafio de código?

O PKCE (RFC 7636) impede a interceptação do código de autorização associando cada código a um verificador de código gerado dinamicamente e conhecido apenas pelo cliente legítimo. O verificador passa por hash para produzir o desafio de código (enviado publicamente). A troca de tokens exige o verificador original. O PKCE impede ataques de interceptação e de injeção. O OAuth 2.1 exige PKCE para todos os fluxos de código de autorização.