Partilhar via

Autenticação e autorização para APIs no Gerenciamento de API do Azure

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 autenticação e a autorização de API no Gerenciamento de API envolvem a proteção da comunicação de ponta a ponta de aplicativos cliente com o gateway de Gerenciamento de API e com 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.

Important

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

Note

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

Aqui está uma breve explicação sobre autenticação e autorização no contexto do acesso a APIs:

  • Autenticação: o processo de verificação da identidade de um usuário ou aplicativo que acessa a API. A autenticação pode ser feita por meio de credenciais como nome de usuário e senha, um certificado ou por meio de logon único (SSO) ou outros métodos.

  • Autorização: o processo de determinar se um usuário ou aplicativo tem permissão para acessar uma API específica, geralmente por meio de um protocolo baseado em token, como o OAuth 2.0.

Note

Para complementar a autenticação e a autorização, você também deve proteger o acesso às APIs usando TLS para proteger as credenciais ou tokens usados para autenticação ou autorização.

Conceitos do OAuth 2.0

O OAuth 2.0 é uma estrutura de autorização padrão amplamente usada 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 (a aplicação de chamada ou portador) usa credenciais para se autenticar com 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 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.

Note

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.

Example:

Tip

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

    Você deve primeiro configurar o Gerenciamento de API 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:

    • Uma política personalizada como send-request para obter um token de acesso consecutivo válido para a API backend de um provedor de identidade configurado.

    • A própria identidade da instância de Gerenciamento de API, passando o token da identidade gerenciada atribuída pelo sistema ou pelo usuário do recurso de Gerenciamento de API para a API de back-end.

  • 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 gerida no gestor 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).

Examples:

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 a 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, você pode usá-los 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

Mechanism Description Considerations
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 utilizadores ou organizações, ou ao tráfego de serviços de origem.
Chave de subscrição Limitar o acesso a uma ou mais APIs com base numa assinatura de API Management 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 usar a chave de assinatura pode ser útil em determinados cenários; por exemplo, rastreando o uso da API por clientes individuais ou concedendo acesso a produtos de API específicos.

Tip

Para uma defesa aprofundada, é altamente recomendável implantar um firewall de aplicativo Web a montante da instância de Gerenciamento de API. Por exemplo, use o Azure Application Gateway ou o Azure Front Door.

Opções do lado do servidor

Mechanism Description Considerations
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 restrito a um recurso de back-end protegido, obtendo um token do Microsoft Entra ID.
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 utilizador e senha que são passados através de um cabeçalho de autorização. Desencorajado se estiverem disponíveis opções de autenticação mais seguras (por exemplo, identidade gerida, certificados, gestor de credenciais). Se escolhido, use valores nomeados para fornecer credenciais com segredos protegidos num cofre de chaves.

Conteúdo relacionado

  • Last updated on