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 inspecionaria as declarações de assunto (sub) declaração ou ID de objeto (oid) e ID de locatário (tid) no token de acesso que o aplicativo fornece ao chamar a API. A API não dependeria do aplicativo não confiável, que é apenas uma chamada vinda de algum lugar da rede. Em vez disso, ele validaria o token para garantir que a API só funcione 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 descrito acima. 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 se tornaria a única autoridade sobre a qual os usuários poderiam alcançar quais 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 poderia 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 acesso de permissão delegada para fornecer à API Downstream quando a API Original faz a chamada. Vamos ver como isso funciona.

O aplicativo cliente adquire o token de acesso para chamar a API original

O diagrama a seguir mostra o Aplicativo Cliente e a API Original.

Título do diagrama: O Aplicativo Cliente adquiriu um token de acesso para chamar a API Original. Legenda do diagrama: O Aplicativo Cliente tem um token de acesso 'A' que permite que ele trabalhe em nome do usuário identificado no token para chamar a API Original.

O Aplicativo Cliente adquiriu um token de acesso de permissão delegado (indicado pela forma do pentágono com o rótulo "A") para a API Original. O token de acesso de permissão delegada permite que ele trabalhe em nome do usuário para chamar a API Original que requer autorização.

O aplicativo cliente fornece token de acesso à API original

A animação a seguir mostra o Aplicativo Cliente dando 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.

O diagrama animado mostra dois diagramas com uma transição de movimento entre o primeiro diagrama e o segundo diagrama. Título do primeiro diagrama: O Aplicativo Cliente adquiriu um token de acesso para chamar a API Original. Legenda do primeiro diagrama: O Aplicativo Cliente tem um token de acesso 'A' que permite que ele trabalhe em nome do usuário identificado no token para chamar a API Original. Segundo título do diagrama: O aplicativo cliente fornece o token de acesso à API original.

A API original executa a validação e a imposição do token

A próxima animação mostra que, 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.

O diagrama animado mostra dois diagramas com uma transição de movimento entre o primeiro diagrama e o segundo diagrama. Título do primeiro diagrama: O aplicativo cliente fornece o token de acesso à API original. Segundo título do diagrama: A API Original executa a validação e imposição do token. Se tudo estiver bom, a API prossegue e atende a solicitação.

A API original não pode usar o token de acesso para chamar a API Downstream

A animação a seguir mostra que a API Original agora deseja chamar uma API Downstream. No entanto, a API Original não pode usar o token de acesso para chamar a API Downstream.

O diagrama animado mostra dois diagramas com uma transição de movimento entre o primeiro diagrama e o segundo diagrama. Título do primeiro diagrama: A API original deseja chamar uma API Downstream. Segundo título do diagrama: A API Original não pode usar o token para chamar a API Downstream.

API original volta para Microsoft Entra ID

Na animação a seguir, 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.

O diagrama animado mostra dois diagramas com uma transição de movimento entre o primeiro diagrama e o segundo diagrama. Título do primeiro diagrama: A API Original não pode usar o token para chamar a API Downstream. Segundo título do diagrama: A API original volta para o Microsoft Entra ID. Segundo subtítulo do diagrama: Precisa de um token de acesso para chamar a API Downstream em nome do usuário.

A animação a seguir mostra a API Original fornecendo o token que a API Original recebeu do Aplicativo Cliente e as credenciais de cliente da API Original.

O diagrama animado mostra dois diagramas com uma transição de movimento entre o primeiro diagrama e o segundo diagrama. Título do primeiro diagrama: A API original volta para o Microsoft Entra ID. Primeira legenda do diagrama: Precisa de um token de acesso para chamar a API Downstream em nome do usuário. Segundo título do diagrama: A API original volta para o Microsoft Entra ID. Legenda do segundo diagrama: fornece o token do Aplicativo Cliente e as credenciais para a API Original.

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).

Microsoft Entra ID executa verificações

Na animação a seguir, o Microsoft Entra ID executa suas verificações. 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.

O diagrama animado mostra dois diagramas com uma transição de movimento entre o primeiro diagrama e o segundo diagrama. Título do primeiro diagrama: A API original volta para o Microsoft Entra ID. Legenda do primeiro diagrama: fornece o token do Aplicativo Cliente e as credenciais para a API Original. Segundo título do diagrama: Microsoft Entra ID verifica acesso condicional, consentimento, etc. Legenda do segundo diagrama: A API Original recebe seu próprio token de acesso para chamar a API Downstream em nome do usuário que entrou no Aplicativo Cliente.

A API original tem contexto de usuário com o fluxo On-Behalf-Of

A animação a seguir ilustra o processo de fluxo em nome de OBO (On-Behalf-Of) que permite que uma API continue a ter o contexto do usuário enquanto chama a API Downstream.

O diagrama animado mostra dois diagramas com uma transição de movimento entre o primeiro diagrama e o segundo diagrama. Título do primeiro diagrama: O processo de fluxo On-Behalf-Of permite que a API Original continue a ter contexto de usuário como chama a API Downstream. Segundo título do diagrama: O processo de fluxo On-Behalf-Of permite que a API Original continue a ter contexto de usuário como chama a API Downstream.

A API original chama a API Downstream

Na animação seguinte, chamamos 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 diagrama animado mostra dois diagramas com uma transição de movimento entre o primeiro diagrama e o segundo diagrama. Título do primeiro diagrama: O processo de fluxo On-Behalf-Of permite que a API Original continue a ter contexto de usuário como chama a API Downstream. Segundo título do diagrama: A API Downstream é chamada. Segundo subtítulo do diagrama: O token que a API Downstream recebe tem declarações adequadas para identificar o usuário do Aplicativo Cliente.

O token inclui os escopos para o consentimento concedido e a identidade original do usuário 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 em nome do fluxo para adquirir tokens para uma API para chamar outra API para garantir que o contexto do usuário passe para todas as APIs Downstream.

Melhor opção: a API original executa o fluxo em nome de

Esta última animação mostra que a melhor opção é que a API Original execute o fluxo On-Behalf-Of (OBO). Se a API Downstream receber o token correto, ela poderá responder corretamente.

O diagrama animado mostra dois diagramas com uma transição de movimento entre o primeiro diagrama e o segundo diagrama. Título do primeiro diagrama: A API Downstream é chamada. Legenda do primeiro diagrama: O token que a API Downstream recebe tem declarações adequadas para identificar o usuário do Aplicativo Cliente. Segundo título do diagrama: A melhor opção é que a API original seja executada "em nome do fluxo". 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

• Fluxos de autenticação da plataforma de identidade da Microsoft e cenários de aplicativos descrevem os fluxos de autenticação e os cenários de aplicativos nos quais eles 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 as informações que você pode 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 de confiança zero do aplicativo 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.
• As práticas recomendadas de segurança para propriedades de aplicativos descrevem URI de redirecionamento, tokens de acesso (usados para fluxos implícitos), 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.