Orientações do programador para o Acesso Condicional ao Microsoft Entra

O recurso Acesso Condicional na ID do Microsoft Entra oferece uma das várias maneiras que você pode usar para proteger seu aplicativo e proteger um serviço. O Acesso Condicional permite que desenvolvedores e clientes corporativos protejam os serviços de várias maneiras, incluindo:

• Autenticação multifator
• Permitir que apenas dispositivos inscritos no Intune acedam a serviços específicos
• Restringindo locais de usuários e intervalos de IP

Para obter mais informações sobre todos os recursos do Acesso Condicional, consulte o artigo O que é Acesso Condicional.

Para desenvolvedores que criam aplicativos para o Microsoft Entra ID, este artigo mostra como você pode usar o Acesso Condicional e você também aprenderá sobre o impacto do acesso a recursos sobre os quais você não tem controle e que podem ter políticas de Acesso Condicional aplicadas. O artigo também explora as implicações do Acesso Condicional no fluxo em nome de, aplicativos Web, acesso ao Microsoft Graph e chamada de APIs.

Pressupõe-se conhecimento de aplicativos únicos e multilocatários e padrões de autenticação comuns.

Como o Acesso Condicional afeta um aplicativo?

Tipos de aplicativos afetados

Na maioria dos casos comuns, o Acesso Condicional não altera o comportamento de um aplicativo nem exige alterações do desenvolvedor. Somente em certos casos, quando um aplicativo solicita indiretamente ou silenciosamente um token para um serviço, um aplicativo requer alterações de código para lidar com desafios de Acesso Condicional. Pode ser tão simples como executar um pedido de início de sessão interativo.

Especificamente, os cenários a seguir exigem código para lidar com desafios de Acesso Condicional:

• Aplicativos que executam o fluxo em nome de
• Aplicações que acedem a vários serviços/recursos
• Aplicativos de página única usando MSAL.js
• Aplicativos Web chamando um recurso

As políticas de acesso condicional podem ser aplicadas ao aplicativo, mas também podem ser aplicadas a uma API da Web acessada pelo aplicativo. Para saber mais sobre como configurar uma política de Acesso Condicional, consulte Guia de início rápido: exigir MFA para aplicativos específicos com o Acesso Condicional do Microsoft Entra.

Dependendo do cenário, um cliente corporativo pode aplicar e remover políticas de Acesso Condicional a qualquer momento. Para que seu aplicativo continue funcionando quando uma nova política for aplicada, implemente o tratamento de desafios. Os exemplos a seguir ilustram o tratamento de desafios.

Exemplos de acesso condicional

Alguns cenários exigem alterações de código para lidar com o Acesso Condicional, enquanto outros funcionam como estão. Aqui estão alguns cenários que usam o Acesso Condicional para fazer autenticação multifator que dão algumas informações sobre a diferença.

• Você está criando um aplicativo iOS de locatário único e aplica uma política de Acesso Condicional. O aplicativo entra em um usuário e não solicita acesso a uma API. Quando o usuário entra, a política é invocada automaticamente e o usuário precisa executar a autenticação multifator (MFA).
• Você está criando um aplicativo nativo que usa um serviço de camada intermediária para acessar uma API downstream. Um cliente corporativo da empresa que usa este aplicativo aplica uma política à API downstream. Quando um usuário final faz login, o aplicativo nativo solicita acesso à camada intermediária e envia o token. A camada intermediária executa o fluxo em nome de para solicitar acesso à API downstream. Neste ponto, um "desafio" de reivindicações é apresentado ao nível médio. A camada intermediária envia o desafio de volta para o aplicativo nativo, que precisa estar em conformidade com a política de Acesso Condicional.

Microsoft Graph

O Microsoft Graph tem considerações especiais ao criar aplicativos em ambientes de Acesso Condicional. Geralmente, a mecânica do Acesso Condicional se comporta da mesma forma, mas as políticas que seus usuários veem serão baseadas nos dados subjacentes que seu aplicativo está solicitando do gráfico.

Especificamente, todos os escopos do Microsoft Graph representam algum conjunto de dados que pode ter políticas aplicadas individualmente. Como as políticas de Acesso Condicional são atribuídas aos conjuntos de dados específicos, a ID do Microsoft Entra impõe políticas de Acesso Condicional com base nos dados por trás do Graph - em vez do próprio Graph.

Por exemplo, se um aplicativo solicitar os seguintes escopos do Microsoft Graph,

scopes="ChannelMessages.Read.All Mail.Read"

Um aplicativo pode esperar que seus usuários cumpram todas as políticas definidas no Teams e no Exchange. Alguns escopos podem ser mapeados para vários conjuntos de dados se ele conceder acesso.

Conformidade com uma política de Acesso Condicional

Para várias topologias de aplicativos diferentes, uma política de Acesso Condicional é avaliada quando a sessão é estabelecida. Como uma política de Acesso Condicional opera com base na granularidade de aplicativos e serviços, o ponto em que ela é invocada depende muito do cenário que você está tentando realizar.

Quando seu aplicativo tenta acessar um serviço com uma política de Acesso Condicional, ele pode encontrar um desafio de Acesso Condicional. Esse desafio é codificado claims no parâmetro que vem em uma resposta do Microsoft Entra ID. Aqui está um exemplo desse parâmetro de desafio:

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Os desenvolvedores podem aceitar esse desafio e anexá-lo a uma nova solicitação ao Microsoft Entra ID. Passar esse estado solicita que o usuário final execute qualquer ação necessária para cumprir a política de Acesso Condicional. Nos cenários a seguir, as especificidades do erro e como extrair o parâmetro são explicadas.

Cenários

Pré-requisitos

O Microsoft Entra Conditional Access é um recurso incluído no Microsoft Entra ID P1 ou P2. Os clientes com licenças do Microsoft 365 Business também têm acesso aos recursos de Acesso Condicional.

Considerações para cenários específicos

As seguintes informações só se aplicam nestes cenários de Acesso Condicional:

• Aplicativos que executam o fluxo em nome de
• Aplicações que acedem a vários serviços/recursos
• Aplicativos de página única usando MSAL.js

As seções a seguir discutem cenários comuns que são mais complexos. O princípio operacional principal é que as políticas de Acesso Condicional são avaliadas no momento em que o token é solicitado para o serviço que tem uma política de Acesso Condicional aplicada.

Cenário: Aplicação a executar o fluxo On-Behalf-Of

Nesse cenário, percorremos o caso em que um aplicativo nativo chama um serviço Web/API. Por sua vez, este serviço faz o fluxo "em nome de" para chamar um serviço a jusante. No nosso caso, aplicamos a nossa política de Acesso Condicional ao serviço downstream (API Web 2) e estamos a utilizar uma aplicação nativa em vez de uma aplicação de servidor/daemon.

A solicitação de token inicial para a API da Web 1 não solicita ao usuário final a autenticação multifator, pois a API da Web 1 nem sempre atinge a API downstream. Quando a API Web 1 tenta solicitar um token em nome do usuário para a API Web 2, a solicitação falha, pois o usuário não entrou com autenticação multifator.

O Microsoft Entra ID retorna uma resposta HTTP com alguns dados interessantes:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Na API Web 1, detetamos o erro error=interaction_requirede enviamos o claims desafio de volta para o aplicativo da área de trabalho. Nesse ponto, o aplicativo da área de trabalho pode fazer uma nova acquireToken() chamada e acrescentar o claimsdesafio como um parâmetro de cadeia de caracteres de consulta extra. Essa nova solicitação requer que o usuário faça a autenticação multifator e, em seguida, envie esse novo token de volta para a API Web 1 e conclua o fluxo em nome de.

Para experimentar esse cenário, consulte nosso exemplo de código .NET. Ele demonstra como passar o desafio de declarações de volta da API Web 1 para o aplicativo nativo e construir uma nova solicitação dentro do aplicativo cliente.

Cenário: Aplicativo acessando vários serviços

Nesse cenário, apresentamos o caso em que um aplicativo Web acessa dois serviços, um dos quais tem uma política de Acesso Condicional atribuída. Dependendo da lógica do aplicativo, pode existir um caminho no qual o aplicativo não exija acesso aos dois serviços Web. Nesse cenário, a ordem na qual você solicita um token desempenha um papel importante na experiência do usuário final.

Vamos supor que temos o serviço Web A e B e o serviço Web B tem a nossa política de Acesso Condicional aplicada. Embora a solicitação de autenticação interativa inicial exija consentimento para ambos os serviços, a política de Acesso Condicional não é necessária em todos os casos. Se o aplicativo solicitar um token para o serviço Web B, a política será invocada e as solicitações subsequentes para o serviço Web A também serão bem-sucedidas da seguinte forma.

Como alternativa, se o aplicativo solicitar inicialmente um token para o serviço Web A, o usuário final não invocará a política de Acesso Condicional. Isso permite que o desenvolvedor do aplicativo controle a experiência do usuário final e não force a política de Acesso Condicional a ser invocada em todos os casos. O caso complicado é se o aplicativo solicitar posteriormente um token para o serviço Web B. Neste ponto, o usuário final precisa estar em conformidade com a política de Acesso Condicional. Quando o aplicativo tenta acquireToken, ele pode gerar o seguinte erro (ilustrado no diagrama a seguir):

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Se o aplicativo estiver usando a biblioteca MSAL, uma falha na aquisição do token será sempre repetida interativamente. Quando essa solicitação interativa ocorre, o usuário final tem a oportunidade de cumprir com o Acesso Condicional. Isso é verdade, a menos que a solicitação seja uma AcquireTokenSilentAsync ou PromptBehavior.Never , nesse caso, o aplicativo precise executar uma solicitação interativa AcquireToken para dar ao usuário final a oportunidade de cumprir a política.

Cenário: Aplicativo de página única (SPA) usando MSAL.js

Nesse cenário, analisamos o caso em que temos um aplicativo de página única (SPA) chamando uma API da Web protegida por Acesso Condicional usando MSAL.js. Esta é uma arquitetura simples, mas tem algumas nuances que precisam ser levadas em conta ao desenvolver em torno do Acesso Condicional.

No MSAL.js, existem algumas funções que obtêm tokens: acquireTokenSilent(), acquireTokenPopup(), e acquireTokenRedirect().

• acquireTokenSilent() pode ser usado para obter silenciosamente um token de acesso, o que significa que ele não mostra a interface do usuário em nenhuma circunstância.
• acquireTokenPopup() e acquireTokenRedirect() ambos são usados para solicitar interativamente um token para um recurso, o que significa que eles sempre mostram a interface do usuário de entrada.

Quando um aplicativo precisa de um token de acesso para chamar uma API da Web, ele tenta um acquireTokenSilent()arquivo . Se o token tiver expirado ou precisarmos cumprir uma política de Acesso Condicional, a função acquireToken falhará e o aplicativo usará acquireTokenPopup() ou acquireTokenRedirect().

Vamos dar um exemplo com nosso cenário de Acesso Condicional. O usuário final acabou de desembarcar no site e não tem uma sessão. Realizamos uma loginPopup() chamada, obtemos um token de ID sem autenticação multifator. Em seguida, o usuário pressiona um botão que exige que o aplicativo solicite dados de uma API da Web. O aplicativo tenta fazer uma acquireTokenSilent() chamada, mas falha, pois o usuário ainda não executou a autenticação multifator e precisa estar em conformidade com a política de Acesso Condicional.

O Microsoft Entra ID envia de volta a seguinte resposta HTTP:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

Nosso aplicativo precisa capturar o error=interaction_required. O aplicativo pode usar um ou acquireTokenPopup()acquireTokenRedirect() no mesmo recurso. O usuário é forçado a fazer uma autenticação multifator. Depois que o usuário conclui a autenticação multifator, o aplicativo recebe um novo token de acesso para o recurso solicitado.

Para experimentar esse cenário, consulte nosso React SPA chamando Node.js API da Web usando o exemplo de código de fluxo em nome de. Este exemplo de código usa a política de Acesso Condicional e a API da Web que você registrou anteriormente com um SPA React para demonstrar esse cenário. Ele mostra como lidar corretamente com o desafio de declarações e obter um token de acesso que pode ser usado para sua API da Web.

Consulte também

• Para saber mais sobre os recursos, consulte Acesso condicional no Microsoft Entra ID.
• Para obter mais exemplos de código do Microsoft Entra, consulte exemplos.
• Para obter mais informações sobre os SDKs do MSAL e acessar a documentação de referência, consulte a Visão geral da Biblioteca de Autenticação da Microsoft.
• Para saber mais sobre cenários multilocatário, consulte Como entrar em usuários usando o padrão multilocatário.
• Saiba mais sobre o Acesso Condicional e a proteção do acesso a aplicativos IoT.