Tokens de acesso pessoal, autenticação máquina-a-máquina e definição de chaves API e seus cenários no mundo real

Se estás a desenvolver um software ou produto SaaS, vais frequentemente deparar-te com um caso de uso amplo ou pedido de funcionalidade: Pedidos API. Especialmente clientes corporativos maiores podem querer acesso programático a recursos, seja a nível pessoal ou organizacional.

Nestes casos, chaves API, Tokens de Acesso Pessoal (PATs) e autenticação Máquina-a-Máquina (M2M) são frequentemente necessários. Neste artigo, vamos explorar as diferenças entre esses métodos e como podem ser usados no desenvolvimento de produtos B2B para desenvolvedores.

As semelhanças#

Primeiro, vamos dar uma olhada nas semelhanças entre os três.

1. Propósito de segurança: Todos os três métodos são usados para proteger e controlar o acesso a APIs, serviços ou recursos. Todos servem como um meio de autenticação e/ou autorização.
2. Abordagem baseada em tokens: Cada método normalmente envolve o uso de uma string ou token únicos para identificação. Esses tokens são geralmente enviados com pedidos API, frequentemente em cabeçalhos ou como parâmetros de consulta.
3. Revogável: Tokens ou chaves em todos os três métodos podem ser revogados ou invalidados se comprometidos ou não forem mais necessários. Isso permite respostas rápidas de segurança sem necessidade de alterar o sistema subjacente.
4. Acesso programável: Todos os três métodos facilitam o acesso programático às APIs ou serviços. Eles permitem automatização e integração entre diferentes sistemas ou aplicações.
5. Auditável: O uso desses métodos de autenticação pode ser registado e auditado. Isso permite rastrear o acesso API, monitorar atividades suspeitas e gerar relatórios de conformidade.
6. Adaptável ao controle de acesso: Todos os três métodos podem ser implementados com vários níveis de controle de acesso e permissões. Eles podem ser adaptados a diferentes modelos de segurança e requisitos arquitetónicos.
7. Independência do protocolo: Embora frequentemente usados com APIs REST, esses métodos podem ser aplicados a vários tipos de APIs e protocolos.

Compreender essas semelhanças ajuda a reconhecer as bases comuns desses métodos de autenticação. As suas diferenças permitem escolher a solução mais apropriada para casos de uso e requisitos de segurança específicos.

Agora, vamos discutir as diferenças, focando nos seus casos de uso e em quando usar cada método.

As diferenças#

Chaves API#

As chaves API são usadas para identificar e autorizar a aplicação ou serviço que envia o pedido. Elas são tipicamente de longa duração e estáticas até serem rotacionadas e frequentemente têm um conjunto fixo de permissões. Elas são principalmente usadas para comunicações de servidor para servidor ou acesso a dados públicos, estes tokens geralmente não representam um utilizador específico.

Como funcionam as chaves API?#

Uma chave API é emitida por um provedor de API e dada a um consumidor API registado [1], que a inclui em cada pedido. O servidor de API verifica então a chave API para validar a identidade do consumidor antes de devolver os dados solicitados.

As chaves API não são tão eficazes quanto outras formas de autenticação API, como OAuth e JWT, mas ainda desempenham um papel importante ao ajudar os produtores de API a monitorizar o uso, mantendo os dados sensíveis seguros.

[1]: Um consumidor API é qualquer aplicação, serviço ou utilizador que interage com uma API para acessar sua funcionalidade ou dados. Eles enviam pedidos para a API para realizar operações como recuperar, criar, atualizar ou excluir recursos. Consumidores API podem ser aplicações web, apps móveis, outros servidores ou até mesmo desenvolvedores individuais que usam a API para integrar com outros serviços ou criar novas funcionalidades em plataformas existentes.

Postman: O que é uma chave API?

Casos de uso#

Quando as pessoas discutem casos de uso de chaves API, elas frequentemente mencionam automação, compartilhamento de dados, testes, desenvolvimento e controle de segurança. No entanto, estes são bastante técnicos. Em cenários do mundo real, o objetivo mais comum ao desenvolver produtos é a integração.

Exemplo 1: Integração com Zapier#

Zapier: Adicionar autenticação com chave API

O Zapier é uma ferramenta de automação popular que conecta diferentes aplicações web. Ao integrar uma aplicação com o Zapier, chaves API são usadas para autenticar e autorizar o acesso à API da aplicação. Por exemplo, se queres automatizar tarefas entre um sistema CRM e uma ferramenta de marketing por email, gerarias uma chave API do sistema CRM e a fornecerias ao Zapier. Esta chave é então usada para autenticar pedidos do Zapier para a API do CRM, permitindo que os dados fluam de forma segura entre os dois sistemas.

Exemplo 2: Integração com Stripe#

O Stripe utiliza chaves API para integrações seguras com várias plataformas e aplicações. Usa o Painel de Desenvolvedores para criar, revelar, eliminar e rodar as chaves API.

Tokens de Acesso Pessoal (PATs)#

Um token de acesso pessoal é outro conceito semelhante, mas representa a identidade e permissões de um utilizador específico, é gerado dinamicamente após autenticação ou login bem sucedido, e tipicamente tem uma duração limitada, mas pode ser renovado. Eles fornecem controle de acesso fino a dados e capacidades específicas do utilizador e frequentemente são usados para ferramentas CLI, scripts ou acesso API pessoal.

Como funcionam os PATs#

1. Criação e gestão: Os utilizadores geram PATs através das configurações de sua conta na plataforma respectiva.
   • Por exemplo, no GitHub, os utilizadores podem criar PATs com permissões específicas e datas de expiração, seja para tokens de grão fino ou clássicos.
   • Em produtos Atlassian como Jira e Confluence, os utilizadores podem criar PATs a partir das configurações do seu perfil, especificando o nome do token e a expiração opcional.
2. Uso: PATs são usados como tokens bearer no cabeçalho de Autorização dos pedidos API. Isso significa que eles estão incluídos nos cabeçalhos HTTP para autenticar o pedido.
   • Eles permitem acesso seguro a recursos API, permitindo que os utilizadores realizem ações como criar, ler, atualizar e excluir recursos com base nas permissões concedidas ao token.
   • PATs podem ser usados em várias aplicações dentro de uma plataforma, fornecendo uma maneira unificada de gerenciar acesso e permissões.
3. Revogar e configurar expiração:
   • PATs oferecem segurança aprimorada ao permitir que os utilizadores revoguem tokens se forem comprometidos, sem necessidade de alterar a senha da conta.
   • As plataformas frequentemente recomendam definir datas de expiração para os PATs para reduzir o risco de exploração de tokens de longa duração.

Casos de uso#

Existem dois cenários típicos,

Automação e scripting

Isto significa quando um desenvolvedor usa um PAT para automatizar o deploy de um código de um repositório para um ambiente de produção, reduzindo a intervenção manual e garantindo consistência.

Por exemplo, utilizadores do GitHub podem criar PATs para autenticar operações Git via HTTPS e interagir com a API REST do GitHub. Isso é útil para desenvolvedores que precisam automatizar tarefas como clonar repositórios, enviar commits ou gerenciar issues e pull requests.

Integração com aplicativos externos

Isto significa habilitar comunicação segura entre diferentes sistemas e aplicações. Isto parece semelhante ao cenário onde integração de chave API, mas o PAT representa o utilizador, não o cliente ou aplicação.

Por exemplo, um gestor de projeto usa um PAT para integrar uma ferramenta de gestão de projetos com um sistema de rastreamento de issues externo, permitindo troca e sincronização de dados sem problemas, como Atlassian (Jira e Confluence).

Os cenários acima são mais como ferramentas de desenvolvedor. Os PATs só são úteis para este tipo de produtos? Não. Aqui estão dois exemplos adicionais: um é um sistema CMS e outro é uma ferramenta de produtividade.

Exemplo 1: Contentful#

Contentful: Tokens de Acesso Pessoal

O Contentful é uma plataforma CMS headless que oferece PATs como uma alternativa aos tokens OAuth para acessar sua API de Gerenciamento de Conteúdo (CMA).

Principais características incluem:

• Utilizadores podem criar múltiplos tokens com diferentes escopos e permissões.
• Tokens são associados à conta do utilizador, herdando as suas permissões.
• PATs são particularmente úteis para fins de desenvolvimento e automação.

Exemplo 2: Airtable#

Criando Tokens de Acesso Pessoal | Suporte Airtable

O Airtable - uma plataforma de colaboração em nuvem, implementa PATs para acesso API.

Seu sistema permite:

• Criação de vários tokens com diferentes escopos e níveis de acesso.
• Os tokens podem ser limitados a bases ou workspaces específicos.
• Administradores empresariais podem criar tokens com acesso mais abrangente em toda a organização.

Autenticação Máquina-a-Máquina (M2M)#

M2M é projetada para comunicação serviço-a-serviço sem intervenção humana. Ela deriva da ideia de que nomes de utilizador e senhas são insuficientes para proteger serviços e não são eficientes para uma automação eficaz.

Aplicações Máquina-a-Máquina (M2M) agora adotam o Fluxo de Credenciais do Cliente, que é definido no protocolo de autorização OAuth 2.0 RFC 6749. Ele também pode suportar protocolos padrão semelhantes. Sim, a autenticação M2M é mais rigorosa quanto ao padrão aberto quando comparada aos PATs e chaves API.

Ela autentica a aplicação ou o serviço em si, não um utilizador, e frequentemente implementa JWT (Tokens Web JSON) para autenticação sem estado. Isto fornece uma maneira segura de os serviços interagirem uns com os outros em sistemas distribuídos.

Como funciona a autenticação máquina-a-máquina#

Segue um processo semelhante:

1. Credenciais do Cliente: Cada máquina (ou serviço) tem um ID de cliente único e um segredo.
2. Pedido de Token: O serviço envia estas credenciais para o servidor de autorização.
3. Token de Acesso: Após a validação, o servidor de autorização emite um token de acesso, frequentemente um JWT (Token Web JSON).
4. Pedidos API: O serviço utiliza este token para autenticar e autorizar pedidos API a outro serviço.
5. Validação: O serviço que recebe valida o token antes de conceder acesso aos seus recursos.

Casos de uso#

Aqui está um exemplo conciso do uso da autenticação máquina-a-máquina (M2M) para comunicação backend-para-backend:

Cenário: O Serviço A precisa acessar dados da API do Serviço B.

1. Configuração:

   • O Serviço A é registado como um cliente com um servidor de autorização.
   • O Serviço A recebe um ID de cliente e um segredo de cliente.

2. Autenticação:

   • O Serviço A solicita um token de acesso do servidor de autorização:

3. Emissão de Token:

   • O servidor de autorização verifica as credenciais e emite um token de acesso JWT.

4. Pedido API:

   • O Serviço A usa o token para solicitar dados do Serviço B:

5. Validação:

   • O Serviço B valida o token com o servidor de autorização.

6. Resposta:

   • Se validado, o Serviço B devolve os dados solicitados para o Serviço A.

Este processo permite uma comunicação segura e automatizada entre o Serviço A e o Serviço B sem intervenção do utilizador, usando o fluxo de credenciais do cliente OAuth 2.0.

Comunicação dispositivo-para-dispositivo

A comunicação dispositivo-para-dispositivo, particularmente no contexto de IoT (Internet das Coisas), depende muito da autenticação máquina-a-máquina (M2M) para garantir intercâmbio de dados seguro e eficiente.

Por exemplo, como dispositivos de casa inteligente, um termostato inteligente comunica-se com um hub de automação residencial central para ajustar as configurações de temperatura com base nas preferências do utilizador. O termostato usa autenticação M2M para enviar dados de forma segura ao hub e receber comandos, garantindo que apenas dispositivos autorizados possam interagir com o sistema de aquecimento da casa.

Resumo principal#

Ok, chegaste ao fim deste artigo. Posso obter um resumo rápido? Claro! Aqui estão os principais pontos:

1. Escopo: As chaves API são amplas, os PATs (Tokens de Acesso Pessoal) são específicos do utilizador e os tokens M2M (Máquina-a-Máquina) são específicos do serviço.
2. Duração: As chaves API têm longa duração, os PATs têm uma duração menor e os tokens M2M podem variar.
3. Representação: As chaves API são strings opacas, os PATs podem ser opacos ou estruturados, e os tokens M2M frequentemente utilizam JWTs.
4. Caso de Uso: As chaves API são para acesso simples à API, os PATs são para operações centradas no utilizador e os tokens M2M são para comunicação serviço-a-serviço.