Autenticação e autorização às APIs na Gestão de API do Azure

  • Artigo

APLICA-SE A: Todas as camadas de gerenciamento de API

Este artigo é uma introdução a um conjunto rico e flexível de recursos no Gerenciamento de API que ajudam a proteger o acesso dos usuários às APIs gerenciadas.

A autorização e autenticação de APIs na Gestão de API implicam assegurar a comunicação ponto a ponto das aplicações clientes no gateway da Gestão de API e através de APIs de back-end. Em muitos ambientes de clientes, o OAuth 2.0 é o protocolo de autorização de API preferido. O Gerenciamento de API oferece suporte à autorização OAuth 2.0 entre o cliente e o gateway de Gerenciamento de API, entre o gateway e a API de back-end ou ambos de forma independente.

Diagrama mostrando pontos de interação para proteger APIs.

O Gerenciamento de API oferece suporte a outros mecanismos de autenticação e autorização do lado do cliente e do lado do serviço que complementam o OAuth 2.0 ou que são úteis quando a autorização do OAuth 2.0 para APIs não é possível. A forma como você escolhe entre essas opções depende da maturidade do ambiente de API da sua organização, dos seus requisitos de segurança e conformidade e da abordagem da sua organização para mitigar ameaças comuns à API.

Importante

Proteger o acesso dos utilizadores às APIs é uma das muitas considerações para proteger o seu ambiente de Gestão de API. Para obter mais informações, consulte Linha de base de segurança do Azure para Gestão de API.

Nota

Outros componentes do Gerenciamento de API têm mecanismos separados para proteger e restringir o acesso do usuário:

  • Para gerenciar a instância de Gerenciamento de API por meio do plano de controle do Azure, o Gerenciamento de API depende do Microsoft Entra ID e do RBAC (controle de acesso baseado em função) do Azure.
  • O portal do desenvolvedor do Gerenciamento de API suporta várias opções para facilitar a inscrição e o login seguros do usuário.

Autenticação versus autorização

Segue-se uma breve explicação dos conceitos de autenticação e autorização no contexto de acesso a APIs:

  • Autenticação - O processo de verificação da identidade de um utilizador ou aplicação que acede à API. A autenticação pode ser feita através de credenciais, como um nome de utilizador e palavra-passe, um certificado ou através do início de sessão único (SSO) ou outros métodos.

  • Autorização - O processo de determinar se um utilizador ou aplicação têm permissões para aceder a uma determinada API, muitas vezes utilizando um protocolo baseado em tokens como o OAuth 2.0.

Nota

Para complementar a autenticação e a autorização, o acesso a APIs também deve ser protegido através de TLS, de forma a proteger as credenciais ou tokens que são utilizados para a autenticação ou para a autorização.

Conceitos do OAuth 2.0

O OAuth 2.0 é uma estrutura de autorização padrão amplamente utilizada para proteger o acesso a recursos como APIs da Web. O OAuth 2.0 restringe as ações do que um aplicativo cliente pode executar em recursos em nome do usuário, sem nunca compartilhar as credenciais do usuário. Embora o OAuth 2.0 não seja um protocolo de autenticação, ele é frequentemente usado com o OpenID Connect (OIDC), que estende o OAuth 2.0 fornecendo autenticação de usuário e funcionalidade SSO.

Fluxo OAuth

O que acontece quando um aplicativo cliente chama uma API com uma solicitação protegida usando TLS e OAuth 2.0? Segue-se um exemplo abreviado de fluxo:

  • O cliente (o aplicativo de chamada ou portador) autentica usando credenciais para um provedor de identidade.

  • O cliente obtém um token de acesso por tempo limitado (um token da Web JSON ou JWT) do servidor de autorização do provedor de identidade.

    O provedor de identidade (por exemplo, Microsoft Entra ID) é o emissor do token, e o token inclui uma declaração de audiência que autoriza o acesso a um servidor de recursos (por exemplo, a uma API de back-end ou ao próprio gateway de Gerenciamento de API).

  • O cliente chama a API e apresenta o token de acesso - por exemplo, em um cabeçalho de autorização.

  • O servidor de recursos valida o token de acesso. A validação é um processo complexo que inclui uma verificação de que as declarações do emissor e do público contêm os valores esperados.

  • Com base em critérios de validação de token, o acesso aos recursos da API de back-end é então concedido.

Dependendo do tipo de aplicativo cliente e cenários, diferentes fluxos de autorização são necessários para solicitar e gerenciar tokens. Por exemplo, o fluxo de código de autorização e o tipo de concessão são comumente usados em aplicativos que chamam APIs da Web. Saiba mais sobre fluxos OAuth e cenários de aplicativos no Microsoft Entra ID.

Cenários de autorização do OAuth 2.0 no Gerenciamento de API

Cenário 1 - O aplicativo cliente autoriza diretamente o back-end

Um cenário de autorização comum é quando o aplicativo de chamada solicita acesso à API de back-end diretamente e apresenta um token OAuth 2.0 em um cabeçalho de autorização para o gateway. Em seguida, o Gerenciamento de API do Azure atua como um proxy "transparente" entre o chamador e a API de back-end e passa o token inalterado para o back-end. O escopo do token de acesso está entre o aplicativo de chamada e a API de back-end.

A imagem a seguir mostra um exemplo em que o Microsoft Entra ID é o provedor de autorização. O aplicativo cliente pode ser um aplicativo de página única (SPA).

Diagrama mostrando a comunicação OAuth onde o público é o back-end.

Embora o token de acesso enviado junto com a solicitação HTTP seja destinado à API de back-end, o Gerenciamento de API ainda permite uma abordagem de defesa em profundidade. Por exemplo, configure políticas para validar o JWT, rejeitando solicitações que chegam sem um token ou um token que não é válido para a API de back-end pretendida. Você também pode configurar o Gerenciamento de API para verificar outras declarações de interesse extraídas do token.

Nota

Se você proteger uma API exposta por meio do Gerenciamento de API do Azure com OAuth 2.0 dessa maneira, poderá configurar o Gerenciamento de API para gerar um token válido para fins de teste em nome de um usuário do console de teste do portal do Azure ou do portal do desenvolvedor. Você precisa adicionar um servidor OAuth 2.0 à sua instância de Gerenciamento de API e habilitar as configurações de autorização do OAuth 2.0 na API. Para obter mais informações, consulte Como autorizar o console de teste do portal do desenvolvedor configurando a autorização de usuário do OAuth 2.0.

Exemplo:

Gorjeta

No caso especial em que o acesso à API é protegido usando o Microsoft Entra ID, você pode configurar a política validate-azure-ad-token para validação de token.

Cenário 2 - O aplicativo cliente autoriza o Gerenciamento de API

Nesse cenário, o serviço de Gerenciamento de API atua em nome da API e o aplicativo de chamada solicita acesso à instância de Gerenciamento de API. O escopo do token de acesso está entre o aplicativo de chamada e o gateway de Gerenciamento de API. No Gerenciamento de API, configure uma política (validate-jwt ou validate-azure-ad-token) para validar o token antes que o gateway passe a solicitação para o back-end. Um mecanismo separado normalmente protege a conexão entre o gateway e a API de back-end.

No exemplo a seguir, o Microsoft Entra ID é novamente o provedor de autorização, e a autenticação TLS mútua (mTLS) protege a conexão entre o gateway e o back-end.

Diagrama mostrando a comunicação OAuth onde o público é o gateway de Gerenciamento de API.

Há diferentes razões para o fazer. Por exemplo:

  • O back-end é uma API herdada que não pode ser atualizada para suportar OAuth

    O Gerenciamento de API deve primeiro ser configurado para validar o token (verificando as declarações do emissor e do público, no mínimo). Após a validação, use uma das várias opções disponíveis para proteger conexões posteriores do Gerenciamento de API, como autenticação TLS mútua (mTLS). Consulte Opções do lado do serviço, mais adiante neste artigo.

  • O contexto exigido pelo back-end não é possível estabelecer a partir do chamador

    Depois que o Gerenciamento de API tiver validado com êxito o token recebido do chamador, ele precisará obter um token de acesso para a API de back-end usando seu próprio contexto ou contexto derivado do aplicativo chamador. Esse cenário pode ser realizado usando:

  • A organização quer adotar uma abordagem de autorização padronizada

    Independentemente dos mecanismos de autenticação e autorização em seus back-ends de API, as organizações podem optar por convergir para o OAuth 2.0 para uma abordagem de autorização padronizada no front-end. O gateway do Gerenciamento de API pode permitir uma configuração de autorização consistente e uma experiência comum para os consumidores de API à medida que os back-ends da organização evoluem.

Cenário 3: O Gerenciamento de API autoriza o back-end

Com conexões gerenciadas (anteriormente chamadas de autorizações), você usa o gerenciador de credenciais no Gerenciamento de API para autorizar o acesso a um ou mais serviços de back-end ou SaaS, como LinkedIn, GitHub ou outros back-ends compatíveis com OAuth 2.0. Nesse cenário, um usuário ou aplicativo cliente faz uma solicitação ao gateway de Gerenciamento de API, com acesso ao gateway controlado usando um provedor de identidade ou outras opções do lado do cliente. Em seguida, por meio da configuração da política, o usuário ou aplicativo cliente delega autenticação de back-end e autorização ao Gerenciamento de API.

No exemplo a seguir, uma chave de assinatura é usada entre o cliente e o gateway, e o GitHub é o provedor de credenciais para a API de back-end.

Diagrama mostrando a autorização para back-end do serviço SaaS usando uma conexão gerenciada no gerenciador de credenciais.

Com uma conexão com um provedor de credenciais, o Gerenciamento de API adquire e atualiza os tokens para acesso à API no fluxo OAuth 2.0. As conexões simplificam o gerenciamento de tokens em vários cenários, como:

  • Um aplicativo cliente pode precisar autorizar vários back-ends SaaS para resolver vários campos usando resolvedores GraphQL.
  • Os usuários se autenticam no Gerenciamento de API por SSO de seu provedor de identidade, mas autorizam um provedor de SaaS de back-end (como o LinkedIn) usando uma conta organizacional comum.
  • Um aplicativo cliente (ou bot) precisa acessar recursos online seguros de back-end em nome de um usuário autenticado (por exemplo, verificando e-mails ou fazendo um pedido).

Exemplos:

Outras opções para proteger APIs

Embora a autorização seja preferida e o OAuth 2.0 tenha se tornado o método dominante de habilitar uma autorização forte para APIs, o Gerenciamento de API fornece vários outros mecanismos para proteger ou restringir o acesso entre cliente e gateway (lado do cliente) ou entre gateway e back-end (lado do serviço). Dependendo dos requisitos da organização, estes podem ser usados para complementar o OAuth 2.0. Como alternativa, configure-os independentemente se os aplicativos de chamada ou APIs de back-end forem herdados ou ainda não suportarem OAuth 2.0.

Opções do lado do cliente

Mecanismo Description Considerações
mTLS Valide o certificado apresentado pelo cliente de conexão e verifique as propriedades do certificado em relação a um certificado gerenciado no Gerenciamento de API O certificado pode ser armazenado em um cofre de chaves.
Restringir IPs do chamador Filtre (permita/negue) chamadas de endereços IP ou intervalos de endereços específicos. Use para restringir o acesso a determinados usuários ou organizações, ou ao tráfego de serviços upstream.
Chave de subscrição Limitar o acesso a uma ou mais APIs com base em uma assinatura do Gerenciamento de API Recomendamos o uso de uma chave de assinatura (API) além de outro método de autenticação ou autorização. Por si só, uma chave de assinatura não é uma forma forte de autenticação, mas o uso da chave de assinatura pode ser útil em determinados cenários, por exemplo, rastreando o uso da API de clientes individuais ou concedendo acesso a produtos de API específicos.

Gorjeta

Para uma defesa aprofundada, recomenda-se vivamente a implementação de um firewall de aplicação Web a montante da instância de Gestão de API. Por exemplo, use o Azure Application Gateway ou o Azure Front Door.

Opções do lado do serviço

Mecanismo Description Considerações
Autenticação de identidade gerenciada Autentique-se na API de back-end com uma identidade gerenciada atribuída pelo sistema ou pelo usuário. Recomendado para acesso com escopo a um recurso de back-end protegido obtendo um token da ID do Microsoft Entra.
Autenticação de certificado Autentique-se na API de back-end usando um certificado de cliente. O certificado pode ser armazenado no cofre de chaves.
Autenticação básica Autentique-se na API de back-end com nome de usuário e senha que são passados por um cabeçalho de autorização. Desencorajado se melhores opções estiverem disponíveis.

Próximos passos