Quais são as diferenças entre clientes públicos e confidenciais?

Ao usar o Logto para criar uma aplicação, irás notar que existem vários tipos de aplicações para escolher, incluindo Aplicação de Página Única (SPA), Aplicação Nativa e Aplicação Web Tradicional. Intuitivamente, pelo nome, é claro que uma Aplicação Nativa executa sistemas operativos comumente encontrados em dispositivos como telemóveis. No entanto, o que são exatamente SPA e Aplicação Web Tradicional? Porque precisamos distinguir entre estes diferentes tipos de apps? Este artigo irá revelar as respostas a estas perguntas.

Antes de começarmos, precisamos fornecer uma breve introdução a alguns conceitos.

O que é OAuth?#

OAuth é um padrão aberto para delegação de acesso, que é tipicamente usado como uma forma para utilizadores da internet concederem a sites ou aplicações acesso às suas informações noutros sites sem fornecer as suas palavras-passe.

Na última década, tornou-se gradualmente o processo de autorização padrão e foi amplamente aceite pela maioria das empresas, como Google, Meta, Microsoft, e assim por diante. A versão atualmente em uso é o OAuth 2.0.

No contexto do OAuth, a aplicação que mencionámos anteriormente é referida como Cliente. Eles podem fazer pedidos para recursos protegidos, desde que tenham obtido a autorização do dono do recurso (normalmente utilizadores finais).

Clientes públicos e clientes confidenciais#

OAuth define dois tipos de clientes, com base na sua capacidade de manter a confidencialidade das credenciais do cliente.

Cliente Confidencial#

Um cliente que é capaz de manter a confidencialidade das suas credenciais (por exemplo, um cliente implementado num servidor seguro com acesso restrito às credenciais do cliente) ou um que é capaz de autenticação segura do cliente por outros meios.

Cliente Público#

Um cliente que é incapaz de manter a confidencialidade das suas credenciais (por exemplo, um cliente que executa no dispositivo do dono do recurso, como uma app nativa ou uma app baseada na web) e também é incapaz de autenticar-se de forma segura como um cliente por quaisquer outros meios.

SPA, aplicação nativa e aplicação web tradicional#

Com o conhecimento prévio acima mencionado, vamos ver o que significam SPA, Aplicação Nativa e aplicação web tradicional no contexto do Logto, assim como se elas são consideradas clientes públicos ou confidenciais.

SPA#

O código do lado do cliente de uma SPA é baixado de um servidor web e executado no agente do utilizador (como um navegador) do dono do recurso no seu dispositivo. Os dados do protocolo e as credenciais são facilmente acessíveis (e frequentemente visíveis) para o dono do recurso.

Aplicação Nativa#

Uma aplicação nativa é instalada e executada no dispositivo do dono do recurso. Os dados do protocolo e as credenciais são acessíveis ao dono do recurso. Geralmente, presume-se que quaisquer credenciais de autenticação do cliente contidas na aplicação podem ser extraídas.

Aplicação Web Tradicional#

Uma aplicação web tradicional é um cliente que executa num servidor web. O dono do recurso acede ao cliente através de uma interface de utilizador HTML apresentada no agente do utilizador no seu dispositivo. As credenciais do cliente, bem como quaisquer tokens de acesso emitidos para o cliente, são armazenados no servidor web e não são expostos ou acessíveis ao dono do recurso.

Então, podemos ver claramente que SPA e aplicação nativa são clientes públicos, enquanto a aplicação web tradicional é um cliente confidencial.

Poderás perceber que, ao criar uma SPA ou aplicação nativa no Logto, não há Segredo da App, enquanto uma aplicação web tradicional tem tanto um ID da App quanto um Segredo da App. Isto porque o segredo de um cliente público não pode ser garantido como seguro.

Como um cliente funciona no fluxo de autorização OAuth?#

Ao desenvolver aplicações OAuth, o primeiro passo é registrar o cliente com o provedor de serviço OAuth. O registro do cliente envolve fornecer detalhes sobre a aplicação, como o seu nome e URI de Redirecionamento. Em seguida, o provedor de serviço OAuth gera um ID de cliente e um segredo de cliente, que são considerados as credenciais da aplicação.

O ID do cliente é considerado informação pública e é partilhado com o utilizador durante o processo OAuth. É tipicamente incluído na URL de autorização e visível para os utilizadores finais.

Por outro lado, o segredo do cliente serve como a palavra-passe para a aplicação e deve ser mantido em segredo. É usado no processo OAuth para trocar o código de autorização (supondo que é o fluxo do código de autorização) para obter o token de acesso. A existência de segredos de cliente garante que apenas aplicações registradas podem completar a troca de tokens de acesso.

Introduzindo Prova de Chave para Troca de Código (PKCE)#

Conforme mencionado anteriormente, os segredos de cliente de clientes públicos não podem ser garantidos como seguros, e atacantes podem obter credenciais de cliente e se passar por clientes para aceder a recursos protegidos, o que é inaceitável em qualquer situação.

PKCE (Prova de Chave para Troca de Código) resolve este problema ao gerar temporariamente um verificador de código no início de cada fluxo de autorização, que é armazenado localmente e hash para gerar um desafio de código que é enviado ao servidor de autorização. O verificador de código é enviado novamente ao servidor de autorização quando se troca o token de acesso. O servidor de autorização verifica que o verificador de código e o desafio de código correspondem, o que garante que o cliente público não foi falsificado.

O verificador de código na PKCE atua como um segredo de cliente dinâmico. Sua segurança é assegurada pela irreversibilidade do algoritmo de hash.

Recapitulação#

Neste artigo, discutimos os conceitos de clientes confidenciais e clientes públicos no OAuth. Aprendemos que clientes confidenciais têm a capacidade de guardar segredos e armazenar informações sensíveis de forma segura, enquanto clientes públicos carecem dessa capacidade. Analisámos exemplos dos dois tipos de clientes, incluindo apps web tradicionais, SPA, e apps nativas no contexto das práticas de produto da Logto.

Também discutimos o processo de registro de clientes no OAuth e os papéis do ID do cliente e do segredo do cliente.

Além disso, descobrimos que clientes públicos enfrentam limitações em armazenar segredos de cliente de forma segura. Para superar esta limitação, introduzimos a PKCE (Prova de Chave para Troca de Código), uma extensão do OAuth que permite que clientes públicos troquem códigos de autorização de forma segura sem a necessidade de um segredo de cliente.

O nosso produto, Logto, é uma solução CIAM abrangente que segue as melhores práticas dos protocolos OAuth e OIDC para garantir segurança em cada etapa, incluindo a adoção do uso da PKCE para proteger a segurança de clientes públicos.