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

Ao usar o Logto para criar um aplicativo, você notará que há vários tipos diferentes de aplicativos para escolher, incluindo Aplicativo de Página Única (SPA), Aplicativo Nativo e Aplicativo Web Tradicional. Intuitivamente, pelo nome, é claro que um Aplicativo Nativo roda em sistemas operacionais comumente encontrados em dispositivos como telefones. No entanto, o que exatamente são SPA e Aplicativo Web Tradicional? Por que precisamos distinguir entre esses diferentes tipos de aplicativos? Este artigo revelará as respostas a essas 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, geralmente usado como uma forma de usuários da internet concederem a sites ou aplicativos acesso às suas informações em outros sites sem fornecerem suas senhas.

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

No contexto do OAuth, o aplicativo que mencionamos anteriormente é referido como Cliente. Eles podem fazer solicitações para recursos protegidos, desde que tenham obtido a autorização do proprietário do recurso (geralmente os usuários finais).

Clientes públicos e clientes confidenciais#

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

Cliente confidencial#

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

Cliente público#

Um cliente que não consegue manter a confidencialidade de suas credenciais (por exemplo, um cliente rodando no dispositivo do proprietário do recurso, como um aplicativo nativo ou aplicativo baseado na web) e não consegue se autenticar de forma segura como cliente por qualquer outro meio.

SPA, aplicativo nativo e aplicativo web tradicional#

Com o conhecimento de base mencionado acima, vamos dar uma olhada no que significam SPA, App Nativo e App Web Tradicional no contexto do Logto, bem como se são considerados clientes públicos ou clientes confidenciais.

SPA#

O código do lado do cliente de um SPA é baixado de um servidor web e executado no agente do usuário (como um navegador web) do proprietário do recurso em seu dispositivo. Os dados do protocolo e credenciais são facilmente acessíveis (e muitas vezes visíveis) para o proprietário do recurso.

App nativo#

Um aplicativo nativo é instalado e executado no dispositivo do proprietário do recurso. Os dados do protocolo e credenciais são acessíveis para o proprietário do recurso. Geralmente, presume-se que quaisquer credenciais de autenticação do cliente contidas dentro do aplicativo possam ser extraídas.

Aplicativo web tradicional#

Um aplicativo web tradicional é um cliente que roda em um servidor web. O proprietário do recurso acessa o cliente por meio de uma interface de usuário HTML apresentada no agente do usuário em seu dispositivo. As credenciais do cliente, assim 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 proprietário do recurso.

Portanto, podemos ver claramente que SPA e aplicativo nativo são clientes públicos, enquanto aplicativo web tradicional é um cliente confidencial.

Você pode perceber que ao criar um SPA ou aplicativo nativo no Logto, não há segredo de App, enquanto um aplicativo web tradicional tem tanto um ID de App quanto um segredo de App. Isso ocorre 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 aplicativos OAuth, o primeiro passo é registrar o cliente com o provedor de serviços OAuth. O registro do cliente envolve fornecer detalhes sobre o aplicativo, como seu nome e URI de Redirecionamento. Então, o provedor de serviços OAuth gera um ID de cliente e um segredo de cliente, que são considerados as credenciais do aplicativo.

O ID de cliente é considerado informação pública e é compartilhado com o usuário durante o processo de OAuth. Ele é normalmente incluído na URL de autorização e visível para os usuários finais.

Por outro lado, o segredo de cliente serve como a senha do aplicativo e deve ser mantido em segredo. Ele é usado no processo OAuth para trocar o código de autorização (assumindo que é o fluxo de código de autorização) para obter o token de acesso. A existência de segredos de cliente garante que apenas aplicativos registrados possam completar a troca de tokens de acesso.

Introduzindo a Proof Key for Code Exchange (PKCE)#

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

PKCE (Proof Key for Code Exchange) resolve esse problema gerando temporariamente um verificador de código no início de cada fluxo de autorização, que é armazenado localmente e transformado em um desafio de código que é enviado para o servidor de autorização. O verificador de código é enviado novamente para o servidor de autorização ao trocar o token de acesso. O servidor de autorização verifica se o verificador de código e o desafio de código correspondem, o que garante que o cliente público não tenha sido falsificado.

O verificador de código no PKCE realmente funciona como um segredo de cliente dinâmico. Sua segurança é garantida 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 manter segredos e armazenar informações sensíveis de forma segura, enquanto clientes públicos não possuem essa habilidade. Examinamos exemplos dos dois tipos de clientes, incluindo aplicativos web tradicionais, SPA e aplicativos nativos, no contexto das práticas de produto do Logto.

Também discutimos o processo de registro do cliente 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 no armazenamento seguro de segredos de clientes. Para superar essa limitação, introduzimos o PKCE (Proof Key for Code Exchange), 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.

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