Autenticação programática: chave de API, token de acesso pessoal e fluxo de credenciais de cliente OAuth

Contexto#

Em desenvolvimento de software, quando precisamos acessar programaticamente recursos de API através de comandos CLI, ou estabelecer comunicação entre serviços de backend, há geralmente três mecanismos de autenticação amplamente usados por nós, desenvolvedores: chave de API, Token de Acesso Pessoal (PAT) e fluxo de credenciais de cliente OAuth (marcado como Machine-to-Machine no Logto). Mas quais são as diferenças entre eles? Qual é o cenário mais adequado para cada um desses métodos? Neste post do blog, vamos nos aprofundar nas semelhanças, diferenças e fornecer insights sobre quando usar cada um em diferentes cenários.

Definições#

• Chave de API: Uma simples string que pode autenticar sua solicitação a um recurso de API.
• Token de Acesso Pessoal (PAT): Também uma string simples, mas representa um usuário quando usada para autenticar em um recurso de API. É uma delegação de um usuário.
• Logto Machine-to-Machine (Logto M2M): Um fluxo padrão de credenciais de cliente OAuth, que requer que um cliente seja registrado previamente, e exige o uso do ID do cliente e segredo para trocar por um token de acesso. Assim, a credencial Logto M2M representa um cliente confiável e a natureza do fluxo de credenciais de cliente OAuth o torna relativamente complicado ao ser utilizado.

Semelhanças#

1. Propósito de autenticação#

• Todos os três, chave de API, PAT e Logto M2M, têm o propósito principal de autenticar um usuário ou uma aplicação para acessar um serviço ou recurso específico. Eles atuam como credenciais para provar a identidade do solicitante, e geralmente são usados em comandos CLI ou cenários de comunicação backend para backend.

2. Medidas de segurança#

• Todos esses três métodos de autenticação devem ser manuseados com segurança em mente. Os desenvolvedores devem garantir armazenamento e transmissão seguros para evitar acesso não autorizado.

Diferenças#

1. Contexto do usuário#

• A chave de API não identifica um principal, nem fornece qualquer informação de autorização. Portanto, as chaves de API são frequentemente usadas para acessar dados ou recursos públicos de forma anônima. Nem todos os serviços são suportados pelo uso de chaves de API.
• PAT são identidades de usuário e o representarão quando forem usadas para solicitar um recurso de API. Em alguns sistemas, PATs não têm permissão para acessar determinados serviços. Ex. Publicação de pacotes NuGet no feed do Azure Artifacts.
• Credenciais Logto M2M só podem ser usadas por clientes confiáveis. O cliente deve ser registrado previamente para ser autenticado. Ao usar credenciais Logto M2M, representam o cliente confiável, em vez do usuário que está utilizando.

2. Granularidade das permissões#

• PAT e credenciais Logto M2M geralmente oferecem um controle mais granular sobre permissões em comparação com a chave de API, permitindo um controle minucioso sobre quais ações podem ser realizadas.

3. Formato do token#

• Chave de API e PAT são geralmente strings de tipo opaco, simples e claras.
• Tokens de acesso que são emitidos através do mecanismo Logto M2M são geralmente no formato JWT.

4. Fluxo de autorização#

• Chave de API e PAT são strings opacas geradas pelo sistema, sem fluxos de autenticação envolvidos durante o processo. Por exemplo, você pode chamar a API de linguagem natural do Google Cloud assim:

• Logto M2M utiliza o fluxo padrão de credenciais de cliente OAuth 2.0. Cada cliente deve obter um par de ID de cliente e segredo do cliente previamente, com o qual o cliente pode trocar por um token de acesso posteriormente. O cliente então usa o token de acesso para acessar o recurso da API.

Quando usar cada um#

Chave de API#

• Comunicação de serviço para serviço: As chaves de API são adequadas para cenários onde aplicações precisam se comunicar com APIs diretamente através de CLIs. Ex. Chamando APIs da OpenAI.
• APIs públicas: Ao expor APIs ao público, as chaves de API fornecem um método direto de controle de acesso.
• Configuração simplificada: Para necessidades de autenticação rápidas e simples, especialmente na fase de desenvolvimento. Ao contrário do Logto M2M, as chaves de API não requerem registro prévio do cliente, e não precisam ser trocadas por um token de acesso. Você apenas passa sua chave de API como um parâmetro em sua solicitação e simplesmente funciona.

Token de Acesso Pessoal (PAT)#

• Ações específicas do usuário: Quando uma aplicação precisa realizar ações em nome de um usuário.
• Controle de acesso granular (usuário): Quando é necessário um controle preciso sobre as ações que um usuário pode realizar.

Logto Machine-to-Machine (Logto M2M)#

• Segurança: Logto M2M é ideal para cenários onde apenas clientes confiáveis têm permissão para acessar os serviços de backend.
• Controle de acesso granular (cliente): Quando é necessário um controle preciso sobre as ações que uma aplicação pode realizar.

Conclusão#

Em resumo, a escolha entre chaves de API, PATs e Logto M2M depende dos requisitos específicos da sua aplicação, se envolve ações específicas do usuário, comunicação de máquina para máquina, ou uma combinação de ambos. Avalie as necessidades de segurança e funcionalidade para determinar o método de autenticação mais apropriado para o seu caso de uso.

O mecanismo Logto M2M permite que usuários definam controles de acesso granulares sobre o recurso RBAC (Controle de Acesso Baseado em Papéis). Também estamos planejando suportar chave de API e PAT em um futuro próximo. Fique ligado para novidades de funcionalidades!