Chamar uma API de outra API

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

Quando um usuário dirige a interface do usuário de um aplicativo, o aplicativo pode utilizar 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 ID de objeto (oid) e 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 pela ID do Microsoft Entra.

Quando uma API (nos referimos a ela como API Original) chama outra, é vital que a API que estamos chamando (nos referimos a ela como 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 validado corretamente.

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 maneira. A API Downstream pode utilizar 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 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 incorreta pode cautilizar sérios problemas de segurança.

Para maior segurança, a API Original adquire um token de acesso com permissão delegada 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 delegada 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.
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 aplicação do token. Depois que o aplicativo cliente fornece o token de acesso à API original, a API original executa a validação e a aplicação do token. Se tudo estiver bem, a API prosseguirá e atendera à 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 utilizar o token de acesso para chamar a API Downstream.
5. A API original volta para a ID do Microsoft Entra. A API Original precisa voltar para a ID do Microsoft Entra. 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 do cliente da API Original.
6. O Microsoft Entra ID executa verificações. O Microsoft Entra ID verifica se há itens como consentimento ou imposição de acesso condicional. Talvez seja necessário voltar ao cliente de chamada e fornecer um motivo para não conseguir obter o token. Normalmente, você utilizaria um processo de desafio de declarações para retornar 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 On-Behalf-Of flow (OBO) permite que uma API continue a ter o contexto do usuário ao chamar a API downstream.
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 apropriada (aud) que indica a API Downstream. O token inclui os escopos para o consentimento concedido e a identidade do usuário do aplicativo original. 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 on-behalf-of 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

A melhor opção é que a API Original execute o On-Behalf-Of flow (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 utilizar 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 utilizar permissões de aplicativo para chamar APIs Downstream quando a API estiver agindo em nome de um usuário.

Próximas etapas

• O artigo Cenários de autenticação e cenários de aplicativo da plataforma de identidade da Microsoft descreve os fluxos de autenticação e os cenários de aplicativo nos quais eles são usados.
• O artigo Proteção de APIs 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 as metas de Confiança Zero.
• O artigo Exemplo de API protegida pela estrutura de consentimento de identidade da Microsoft ajuda você a projetar estratégias de permissões de aplicativos com privilégios mínimos para oferecer 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, aumentando a segurança de Confiança Zero do aplicativo com privilégios mínimos.
• O módulo de aprendizado Proteger APIs personalizadas com identidade da Microsoft explica como proteger uma API Web com a identidade da Microsoft e como chamá-la de outro aplicativo.
• Práticas recomendadas de segurança para propriedades de aplicativo descreve o URI de redirecionamento, tokens de acesso, certificados e segredos, URI de ID do aplicativo e propriedade do aplicativo.
• O artigo Bibliotecas de autenticação de plataforma de identidade da Microsoft descreve o suporte da Biblioteca de Autenticação da Microsoft para vários tipos de aplicativos.