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 inspecionaria as declarações de declaração de assunto (sub) 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 funcione apenas em nome do usuário do aplicativo que o Microsoft Entra ID verificou.
Quando uma API (que a chamamos de API Original) chama outra, é vital que a API que estamos chamando (nos referimos a ela como a 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 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 se tornaria a única autoridade sobre a qual os usuários poderiam 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.
O aplicativo cliente adquire token de acesso para chamar a API original
O diagrama a seguir mostra o Aplicativo Cliente e a API Original.
O Aplicativo Cliente adquiriu um token de acesso de permissão delegada (indicado pela forma 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.
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 bem, a API prosseguirá e atendera à solicitação para o Aplicativo Cliente.
A API original não pode utilizar 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 utilizar o token de acesso para chamar a API Downstream.
API original volta para o 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.
A próxima animação mostra a API Original fornecendo o token que a API Original recebeu do Aplicativo Cliente e as credenciais de cliente da API Original.
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).
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.
A API original tem contexto de usuário com fluxo On-Behalf-Of
A animação a seguir ilustra o processo de fluxo On-Behalf-Of (OBO) que permite que uma API continue a ter o contexto do usuário ao chamar a API Downstream.
API original chama API Downstream
Na próxima animação, chamamos 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
Essa ú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.
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. Esse artigo 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.
- O artigo Práticas recomendadas de segurança para propriedades de aplicativos descreve o URI de redirecionamento, tokens de acesso (usados para fluxos implícitos), certificados e segredos, URI de ID do aplicativo e propriedade de aplicativos.
- 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.