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

  • Artigo

APLICA-SE A: todas as camadas do Gerenciamento de API

Este artigo é uma introdução a um conjunto avançado e flexível de recursos em Gerenciamento de API que ajudam você a proteger o acesso dos usuários a APIs gerenciadas.

A autenticação e a autorização de API em Gerenciamento de API envolvem a comunicação de ponta a ponta de aplicativos cliente por meio do gateway de Gerenciamento de API para APIs de back-end. Em muitos ambientes de cliente, o OAuth 2.0 é o protocolo de autorização de API preferencial. O Gerenciamento de API dá suporte à autorização do 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 dá 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 requisitos de segurança e conformidade e da abordagem da sua organização para mitigar ameaças comuns à API.

Importante

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

Observação

Outros componentes 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 da ID do Microsoft Entra e do RBAC (controle de acesso baseado em função) do Azure.
  • O portal do desenvolvedor do Gerenciamento de API dá suporte a várias opções para facilitar a inscrição e a entrada seguras do usuário.

Autenticação versus autorização

Aqui está uma breve explicação da autenticação e autorização no contexto de acesso às 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.

Observação

Para complementar a autenticação e a autorização, o acesso às APIs também deve ser protegido por meio de TLS para proteger as credenciais ou tokens usados para autenticação ou autorização.

Conceitos do OAuth 2.0

OOAuth 2.0 é uma estrutura de autorização padrão amplamente usada para proteger o acesso a recursos como APIs 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 geralmente é usado com o OpenID Connect (OIDC), que estende o OAuth 2.0 fornecendo autenticação de usuário e funcionalidade de SSO.

Fluxo do OAuth

O que acontece quando um aplicativo cliente chama uma API com uma solicitação protegida por meio de TLS e OAuth 2.0? Veja a seguir um fluxo de exemplo abreviado:

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

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

    O provedor de identidade (por exemplo, a ID do Microsoft Entra) é o emissor do token e o token inclui uma declaração de público que autoriza o acesso a um servidor de recursos (por exemplo, para uma API de back-end ou para o 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 da audiência contêm valores esperados.

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

Dependendo do tipo de aplicativo cliente e cenários, diferentes fluxos de autenticaçã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 Web. Saiba mais sobre os fluxos do OAuth e os cenários de aplicativo na ID do Microsoft Entra.

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. O Gerenciamento de API do Azure atua como um proxy "transparente" entre o chamador e a API de back-end e passa o token por meio de 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 a ID do Microsoft Entra é o provedor de autorização. O aplicativo cliente pode ser um aplicativo de página única (SPA).

Diagrama mostrando a comunicação de OAuth em que a audiência é 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 Gerenciamento de API para verificar outras declarações de interesse extraídas do token.

Observação

Se você proteger uma API exposta por meio Gerenciamento de API do Azure com o OAuth 2.0 dessa forma, poderá configurar 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 desenvolvedor. Você precisa adicionar um servidor OAuth 2.0 à instância do 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:

Dica

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

Cenário 2: o aplicativo cliente autoriza a 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 Gerenciamento de API. Em 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, a ID do Microsoft Entra é 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 de OAuth em que a audiência é o gateway de Gerenciamento de API.

Há diferentes razões para se querer fazer isso. Por exemplo:

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

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

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

    Depois que Gerenciamento de API validar 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 o contexto derivado do aplicativo de chamada. Esse cenário pode ser realizado usando:

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

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

  • A organização deseja 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 no OAuth 2.0 para uma abordagem de autorização padronizada no front-end. o gateway do Gerenciamento de API pode habilitar a 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 para o gateway de Gerenciamento de API, com acesso de gateway controlado usando um provedor de identidade ou outras opções do lado do cliente. Em seguida, por meio da configuração de política, o usuário ou aplicativo cliente delega autenticação e autorização de back-end para 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 o serviço de SaaS de back-end usando uma conexão gerenciada no gerenciador de credenciais.

Com uma conexão a um provedor de credenciais, o Gerenciamento de API adquire e atualiza os tokens para acesso à API no fluxo do 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 de SaaS para resolve vários campos usando resolvedores de 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 protegidos de back-end em nome de um usuário autenticado (por exemplo, verificando emails ou fazendo um pedido).

Exemplos:

Outras opções para proteger APIs

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

Opções do lado do cliente

Mecanismo Descrição Considerações
mTLS Validar o certificado apresentado pelo cliente de conexão e marcar propriedades de certificado em relação a um certificado gerenciado em Gerenciamento de API O certificado pode ser armazenado em um cofre de chaves.
Restringir IP do autor da chamada Filtrar (permitir/negar) 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 de upstream.
Chave de assinatura Limitar o acesso a uma ou mais APIs com base em uma assinatura Gerenciamento de API É recomendável usar 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, para acompanhar o uso da API de clientes individuais ou para conceder acesso a produtos de API especpificos.

Dica

Para defesa detalhada, é altamente recomendável implantar um upstream de firewall de aplicativo Web da instância de Gerenciamento de API. Por exemplo, use o Gateway de Aplicativo do Azure ou o Azure Front Door.

Opções do lado do serviço

Mecanismo Descrição Considerações
Autenticação de identidade gerenciada Autentique-se na API de back-end com uma identidade gerenciada atribuída pelo sistema ou atribuída 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 por meio de um certificado do cliente. O certificado pode ser armazenado no cofre de chaves.
Autenticação Básica Autentique-se na API de back-end com o nome de usuário e a senha que são passados por meio de um cabeçalho de Autorização. Não recomendável se opções melhores estiverem disponíveis.

Próximas etapas