Chamar uma API de outra API

Como você, como desenvolvedor, garante o Zero Trust quando tem uma API que precisa chamar outra API? Neste artigo, você aprenderá como desenvolver seu aplicativo com segurança quando ele estiver trabalhando em nome de um usuário.

Quando um usuário dirige a interface do usuário de um aplicativo, o aplicativo pode usar uma permissão delegada para que a API saiba qual usuário em nome do qual o aplicativo está trabalhando. Ele inspeciona a declaração de assunto (sub) ou as declarações de ID de objeto (oid) e as declarações de ID de locatário (tid) no token de acesso que o aplicativo fornece ao chamar a API. A API não depende do aplicativo não confiável, que é apenas uma chamada vinda de algum lugar da rede. Em vez disso, ele valida o token para garantir que a API funcione apenas em nome do usuário do aplicativo verificado pelo ID do Microsoft Entra.

Quando uma API (que chamamos de API Original) chama outra, é vital que a API que estamos chamando (chamamos de API Downstream) siga o processo de validação. A API Downstream não pode depender de uma fonte de rede não confiável. Ele deve obter a identidade do usuário de um token de acesso devidamente validado.

Se a API Downstream não seguir o processo de validação adequado, a API Downstream deverá confiar na API Original para fornecer a identidade do usuário de outra forma. A API Downstream pode usar incorretamente uma permissão de aplicativo para executar a operação. Em seguida, a API Original torna-se a única autoridade sobre a qual os usuários podem obter os resultados em relação à API Downstream. A API original pode intencionalmente (ou não) permitir que um usuário realize uma tarefa que o usuário não pode realizar de outra forma. Por exemplo, um usuário pode alterar os detalhes de outro usuário ou ler e atualizar documentos que o usuário não tem permissão para acessar. A validação inadequada pode causar sérios problemas de segurança.

Para maior segurança, a API Original adquire um token de permissão delegada de acesso para fornecer à API Downstream quando a API Original faz a chamada. Vamos ver como isso funciona.

1. O Aplicativo Cliente adquire o token de acesso para chamar a API Original. O Aplicativo Cliente adquire um token de acesso de permissão delegado à API Original. O token de acesso de permissão delegada permite atuar em nome do usuário para chamar a API original que requer autorização.
2. O aplicativo cliente fornece token de acesso à API original. O Aplicativo Cliente fornece o token de acesso à API Original. A API Original valida e inspeciona totalmente o token de acesso para determinar a identidade do usuário do Aplicativo Cliente.
3. A API original executa a validação e a imposição do token. Depois que o Aplicativo Cliente fornece o token de acesso à API Original, a API Original executa a validação e a imposição do token. Se tudo estiver bom, a API prossegue e atende a solicitação para o Aplicativo Cliente.
4. A API original não pode usar o token de acesso para chamar a API Downstream. A API Original deseja chamar uma API Downstream. No entanto, a API Original não pode usar o token de acesso para chamar a API Downstream.
5. A API original regressa ao Microsoft Entra ID. A API original precisa voltar para o Microsoft Entra ID. Ele precisa de um token de acesso para chamar a API Downstream em nome do usuário. A API Original fornece o token que a API Original recebeu do Aplicativo Cliente e as credenciais de cliente da API Original.
6. O Microsoft Entra ID executa verificações. O Microsoft Entra ID verifica coisas como consentimento ou imposição de acesso condicional. Você pode ter que voltar para o seu cliente de chamada e fornecer um motivo para não ser capaz de obter o token. Normalmente, você usaria um processo de contestação de declarações para voltar ao aplicativo de chamada com informações sobre o consentimento não recebido (como estar relacionado a políticas de acesso condicional). Se tudo estiver bem, o Microsoft Entra ID emitirá um token de acesso à API Original para chamar a API Downstream em nome do usuário.
7. A API original tem contexto de usuário com fluxo On-Behalf-Of. O processo de fluxo On-Behalf-Of (OBO) permite que uma API continue a ter o contexto do utilizador enquanto chama a API a jusante.
8. A API original chama a API Downstream. Chame a API Downstream. O token que a API Downstream recebe tem a declaração de audiência adequada (aud) que indica a API Downstream. O token inclui os escopos para o consentimento concedido e a identidade do utilizador original do aplicativo. A API Downstream pode implementar corretamente permissões efetivas para garantir que o usuário identificado tenha permissão para realizar a tarefa solicitada. Você deseja usar o fluxo 'em nome de' para adquirir tokens para que uma API possa chamar outra API, garantindo que o contexto do usuário seja transferido para todas as APIs a jusante.

Melhor opção: a API original executa o fluxo Em-Nome-De

A melhor opção é que a API Original execute o fluxo de On-Behalf-Of (OBO). Se a API Downstream receber o token correto, ela poderá responder corretamente. Quando uma API está agindo em nome de um usuário e precisa chamar outra API, a API deve usar o OBO para adquirir um token de acesso de permissão delegada para chamar a API Downstream em nome do usuário. As APIs nunca devem usar permissões de aplicativo para chamar APIs Downstream quando a API estiver agindo em nome de um usuário.

Próximos passos

• Cenários de aplicações e fluxos de autenticação da plataforma de identidade da Microsoft descrevem os fluxos de autenticação e os cenários de aplicações nos quais são usados.
• A Proteção de API descreve as práticas recomendadas para proteger sua API por meio de registro, definição de permissões e consentimento e imposição de acesso para atingir suas metas de Zero Trust.
• Exemplo de API protegida pela estrutura de consentimento de identidade da Microsoft ajuda você a projetar estratégias de permissões de aplicativo de privilégios mínimos para a melhor experiência do usuário.
• Personalizar tokens descreve a informação que é possível receber nos tokens do Microsoft Entra. Ele explica como personalizar tokens para melhorar a flexibilidade e o controle e, ao mesmo tempo, aumentar a segurança do aplicativo Zero Trust com o menor privilégio.
• O módulo Secure custom APIs with Microsoft Identity Learn explica como proteger uma API da Web com identidade da Microsoft e como chamá-la de outro aplicativo.
• Práticas recomendadas de segurança para propriedades de aplicativos descreve o URI de redirecionamento, tokens de acesso, certificados e segredos, URI de ID de aplicativo e propriedade do aplicativo.
• As bibliotecas de autenticação da plataforma de identidade da Microsoft descrevem o suporte da Biblioteca de Autenticação da Microsoft para vários tipos de aplicativos.