O que é o PKCE: dos conceitos básicos à compreensão profunda

Proof Key for Code Exchange (PKCE) é uma extensão do fluxo de código de autorização, originalmente desenhada para proteger o fluxo de código de autorização em aplicações móveis, e agora é recomendada para ser usada também por aplicações de página única. A partir do OAuth 2.1, o PKCE é obrigatório para todos os tipos de clientes, incluindo clientes públicos e clientes confidenciais (privados).

Neste artigo, vamos ajudá-lo a entender por que o PKCE foi criado e como ele protege as suas aplicações, dando-lhe uma compreensão profunda do PKCE.

Por que o PKCE é necessário?#

No fluxo de código de autorização do OAuth 2.0, os utilizadores pedem para iniciar sessão através de uma aplicação. O servidor de autenticação direciona os utilizadores para uma página de autenticação. Após a autenticação do utilizador, o servidor devolve um código de autorização à aplicação, que depois usa este código para solicitar um token de acesso ao servidor de autenticação.

Este fluxo tem um risco de segurança significativo: o código de autorização pode ser interceptado por programas maliciosos. Isto é particularmente preocupante em dispositivos móveis, onde outras aplicações podem registar o mesmo URI de redirecionamento e interceptar o código de autorização.

O processo de interceptação é mostrado no diagrama abaixo:

Passo (1): A aplicação realiza um pedido de autenticação através de uma API segura que não pode ser interceptada. Neste passo, o requisitante também fornece um URI de redirecionamento.

Passo (2): O pedido é então encaminhado para o servidor de autorização do OAuth 2.0. Como o OAuth requer o uso de TLS, esta comunicação é protegida por TLS e não pode ser interceptada.

Passo (3): O servidor de autorização devolve o código de autorização.

Passo (4.a): o código de autorização é devolvido ao requisitante através do URI de redirecionamento que foi fornecido no passo (1). Neste passo, se a aplicação maliciosa se registou como uma manipuladora para o URI de redirecionamento, então a aplicação maliciosa pode interceptar o código de autorização. Com o código de autorização, o atacante pode solicitar e obter um token de acesso nos passos (5.a) e (6.a), respectivamente.

Como mostrado acima, no fluxo de código de autorização do OAuth 2.0, se o código de autorização for interceptado, os atacantes podem usá-lo para obter tokens de acesso. Portanto, precisamos de um mecanismo para impedir a interceptação de códigos de autorização, o que levou à criação do PKCE.

Como funciona o PKCE?#

Como mencionado acima, se quisermos evitar ser atacados, precisamos garantir que apenas a aplicação que iniciou o pedido possa solicitar e obter o token de acesso. É aqui que o PKCE entra em jogo.

O PKCE resolve esse problema ao introduzir um conceito de "chave de prova".

Ao solicitar um código de autorização, a aplicação primeiro gera um verificador de código aleatório e armazena-o localmente. Ela então converte este verificador de código em um desafio de código usando algoritmos específicos. A aplicação envia tanto o desafio de código quanto o método de desafio de código para o servidor de autenticação durante o pedido de código de autorização.

O verificador de código é uma string gerada aleatoriamente, e o desafio de código é derivado do verificador de código através da conversão. Dois métodos de conversão são suportados:

• plain: Usa o verificador de código diretamente como o desafio de código

• S256: Aplica hashing SHA-256 ao verificador de código, seguido de codificação Base64URL. Como a saída do hash não pode ser revertida para obter o verificador de código, e porque o método plain pode ser vulnerável a ataques man-in-the-middle durante a transmissão, usar S256 é fortemente recomendado por razões de segurança.

Após a autenticação do utilizador, o servidor de autenticação devolve o código de autorização à aplicação. Quando solicita um token de acesso, a aplicação envia tanto o código de autorização como o verificador de código para o servidor de autenticação. O servidor transforma o "verificador de código" usando o "método de desafio de código" previamente recebido e compara o resultado com o "desafio de código" previamente recebido para verificar a posse do "verificador de código" pelo cliente.

Passo (1-3): A aplicação cria e regista um segredo denominado "verificador de código" e deriva uma versão transformada "desafio de código", que é enviada no Pedido de Autorização do OAuth 2.0 juntamente com o método de transformação "método de desafio de código".

Passo (3-6): O Servidor de Autenticação responde como de costume mas armazena o "desafio de código" e o "método de desafio de código".

Passo (7.a): A aplicação então envia o código de autorização para o endpoint do token como de costume mas inclui o segredo "verificador de código" gerado no passo (1).

Passo (8.a-9.a): O servidor de autorização transforma o "verificador de código" em "desafio de código" e compara-o com o "desafio de código" do passo (1-3). O acesso é negado se não forem iguais.

Neste caso, mesmo que a aplicação maliciosa tenha interceptado o código de autorização no passo (6.b), ela é incapaz de trocá-lo por um token de acesso, pois não possui o segredo "verificador de código", e como o "verificador de código" é enviado sobre TLS, ele não pode ser interceptado.

Resumo#

Este artigo explica como o PKCE funciona e por que é necessário para proteger o fluxo de código de autorização. Ao adicionar um mecanismo de chave de prova, o PKCE impede que aplicações maliciosas interceptem e utilizem indevidamente códigos de autorização. Esperamos que esta explicação o ajude a entender o PKCE em profundidade.