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

Prova de Chave para Troca de Código (PKCE) é uma extensão do fluxo de código de autorização, foi originalmente projetada para proteger o fluxo de código de autorização em aplicativos móveis, e agora é recomendada para ser usada por aplicativos de página única também. A partir do OAuth 2.1, o PKCE é aplicado para todos os tipos de clientes, incluindo clientes públicos e clientes confidenciais (privados).

Neste artigo, vamos ajudar você a entender por que o PKCE foi criado e como ele protege seus aplicativos, proporcionando uma compreensão aprofundada do PKCE.

Por que o PKCE é necessário?#

No fluxo de código de autorização OAuth 2.0, os usuários solicitam login por meio de um aplicativo. O servidor de autenticação direciona os usuários para uma página de autenticação. Após a autenticação do usuário, o servidor retorna um código de autorização para o aplicativo, que então usa esse código para solicitar um token de acesso ao servidor de autenticação.

Este fluxo possui um risco de segurança significativo: o código de autorização pode ser interceptado por programas maliciosos. Isso é particularmente preocupante em dispositivos móveis, onde outros aplicativos podem registrar o mesmo URI de redirecionamento e interceptar o código de autorização.

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

Passo (1): O app realiza uma solicitação de autorização por meio de uma API segura que não pode ser interceptada. Neste passo, o solicitante também fornece um URI de redirecionamento.

Passo (2): A solicitação é então encaminhada para o servidor de autorização OAuth 2.0. Como o OAuth exige o uso de TLS, essa comunicação é protegida por TLS e não pode ser interceptada.

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

Passo (4.a): o código de autorização é retornado para o solicitante via o URI de redirecionamento fornecido no passo (1). Neste passo, se o aplicativo malicioso tiver se registrado como um manipulador para o URI de redirecionamento, então o aplicativo malicioso pode interceptar o código de autorização. Com o código de autorização, o invasor pode solicitar e obter um token de acesso nos passos (5.a) e (6.a), respectivamente.

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

Como o PKCE funciona?#

Como mencionado acima, se queremos evitar sermos atacados, precisamos garantir que apenas o aplicativo que iniciou a solicitação possa solicitar e obter o token de acesso. É aqui que o PKCE entra em ação.

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

Ao solicitar um código de autorização, o aplicativo primeiro gera um código verificador aleatório e o armazena localmente. Em seguida, converte esse código verificador em um desafio de código usando algoritmos específicos. O aplicativo envia tanto o desafio de código quanto o método de desafio de código para o servidor de autenticação durante a solicitação de código de autorização.

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

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

• S256: Aplica hashing SHA-256 ao código verificador, seguido por codificação Base64URL. Como a saída do hash não pode ser revertida para obter o código verificador, 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 usuário, o servidor de autenticação retorna o código de autorização para o aplicativo. Ao solicitar um token de acesso, o aplicativo envia tanto o código de autorização quanto o código verificador para o servidor de autenticação. O servidor transforma o "código verificador" usando o "método de desafio de código" recebido anteriormente e compara o resultado com o "desafio de código" recebido anteriormente para verificar a posse do "código verificador" pelo cliente.

Passo (1-3): O app cria e registra um segredo chamado "código verificador" e deriva uma versão transformada "desafio de código", que é enviado na Solicitação de Autorização OAuth 2.0 juntamente com o método de transformação "método de desafio de código".

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

Passo (7.a): O app então envia o código de autorização ao endpoint de token como de costume, mas inclui o segredo "código verificador" gerado no passo (1).

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

Neste caso, mesmo que o aplicativo malicioso tenha interceptado o código de autorização no passo (6.b), ele é incapaz de resgatá-lo por um token de acesso, pois não está na posse do segredo "código_verificador", e como o "código verificador" é enviado via 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 prova de chave, o PKCE impede que aplicativos maliciosos interceptem e usem indevidamente códigos de autorização. Espero que esta explicação ajude você a entender o PKCE em profundidade.