Configurar o Serviço de Aplicativo ou o aplicativo Azure Functions para usar a entrada do Microsoft Entra

  • Artigo

Selecione outro provedor de autenticação para ir até ele.

Este artigo mostra como configurar a autenticação para o Serviço de Aplicativo do Azure ou o Azure Functions para que seu aplicativo entre em usuários com a plataforma de identidade da Microsoft (ID do Microsoft Entra) como o provedor de autenticação.

O recurso Autenticação do Serviço de Aplicativo pode criar automaticamente um registro de aplicativo com a plataforma de identidade da Microsoft. Você também pode usar um registro que você ou um administrador de diretório cria separadamente.

Nota

A opção de criar um novo registro automaticamente não está disponível para nuvens governamentais ou ao usar [Microsoft Entra ID for customers (Preview)]. Em vez disso, defina um registro separadamente.

Opção 1: Criar um novo registro de aplicativo automaticamente

Use essa opção, a menos que você precise criar um registro de aplicativo separadamente. Você pode personalizar o registro do aplicativo no Microsoft Entra ID depois de criado.

  1. Entre no portal do Azure e navegue até seu aplicativo.

  2. Selecione Autenticação no menu à esquerda. Selecione Adicionar provedor de identidade.

  3. Selecione Microsoft na lista suspensa do provedor de identidade. A opção para criar um novo registo é selecionada por predefinição. Pode alterar o nome do registo ou os tipos de conta suportados.

    Um segredo do cliente será criado e armazenado como uma configuração de aplicativo adesivo de slot chamada MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Você pode atualizar essa configuração posteriormente para usar referências do Cofre da Chave se desejar gerenciar o segredo no Cofre da Chave do Azure.

  4. Se este for o primeiro provedor de identidade configurado para o aplicativo, você também será solicitado com uma seção de configurações de autenticação do Serviço de Aplicativo. Caso contrário, você pode passar para a próxima etapa.

    Essas opções determinam como seu aplicativo responde a solicitações não autenticadas, e as seleções padrão redirecionarão todas as solicitações para entrar com esse novo provedor. Você pode alterar esse comportamento agora ou ajustar essas configurações posteriormente na tela principal Autenticação escolhendo Editar ao lado de Configurações de autenticação. Para saber mais sobre essas opções, consulte Fluxo de autenticação.

  5. (Opcional) Selecione Avançar: Permissões e adicione as permissões do Microsoft Graph necessárias para o aplicativo. Estes serão adicionados ao registo da aplicação, mas também pode alterá-los mais tarde.

  6. Selecione Adicionar.

Agora você está pronto para usar a plataforma de identidade da Microsoft para autenticação em seu aplicativo. O provedor será listado na tela Autenticação . A partir daí, você pode editar ou excluir essa configuração do provedor.

Para obter um exemplo de configuração do início de sessão do Microsoft Entra para uma aplicação Web que acede ao Armazenamento do Azure e ao Microsoft Graph, consulte este tutorial.

Opção 2: Usar um registro existente criado separadamente

Você pode configurar a autenticação do Serviço de Aplicativo para usar um registro de aplicativo existente. As seguintes situações são os casos mais comuns para usar um registro de aplicativo existente:

  • Sua conta não tem permissões para criar registros de aplicativos em seu locatário do Microsoft Entra.
  • Você deseja usar um registro de aplicativo de um locatário do Microsoft Entra diferente daquele em que seu aplicativo está.
  • A opção de criar um novo registro não está disponível para nuvens governamentais.

Etapa 1: Criar um registro de aplicativo na ID do Microsoft Entra para seu aplicativo do Serviço de Aplicativo

Durante a criação do registro do aplicativo, colete as seguintes informações que você precisará mais tarde quando configurar a autenticação no aplicativo do Serviço de Aplicativo:

  • ID de Cliente
  • ID de Inquilino do
  • Segredo do cliente (opcional, mas recomendado)
  • URI da ID do aplicativo

As instruções para criar um registro de aplicativo dependem se você estiver usando um locatário da força de trabalho ou um locatário do cliente. Use as guias abaixo para selecionar o conjunto certo de instruções para seu cenário.

Para registrar o aplicativo, execute as seguintes etapas:

  1. Entre no portal do Azure, pesquise e selecione Serviços de Aplicativo e selecione seu aplicativo. Anote o URL do seu aplicativo. Você o usará para configurar o registro do aplicativo Microsoft Entra.

  2. Navegue até o seu locatário no portal:

    No menu do portal, selecione Microsoft Entra ID. Se o locatário que você está usando for diferente daquele que você usa para configurar o aplicativo do Serviço de Aplicativo, você precisará alterar os diretórios primeiro.

  3. Na tela "Visão geral", anote a ID do locatário, bem como o domínio principal.

  4. Na navegação à esquerda, selecione Registos de>aplicações Novo registo.

  5. Na página Registar uma aplicação, introduza um Nome para o registo da sua aplicação.

  6. Em Tipos de conta suportados, selecione o tipo de conta que pode aceder a esta aplicação.

  7. Na seção Redirecionar URIs, selecione Web para plataforma e digite <app-url>/.auth/login/aad/callback. Por exemplo, https://contoso.azurewebsites.net/.auth/login/aad/callback.

  8. Selecione Registar.

  9. Depois que o registro do aplicativo for criado, copie a ID do aplicativo (cliente) e a ID do diretório (locatário) para mais tarde.

  10. Na navegação à esquerda, selecione Autenticação. Em Concessão implícita e fluxos híbridos, habilite tokens de ID para permitir entradas de usuário do OpenID Connect a partir do Serviço de Aplicativo. Selecione Guardar.

  11. (Opcional) Na navegação à esquerda, selecione Propriedades de identidade visual e outras. Em URL da página inicial, insira a URL do seu aplicativo do Serviço de Aplicativo e selecione Salvar.

  12. Na navegação à esquerda, selecione Expor uma API>Adicionar>salvar. Esse valor identifica exclusivamente o aplicativo quando ele é usado como um recurso, permitindo que sejam solicitados tokens que concedem acesso. Ele é usado como um prefixo para escopos que você cria.

    Para um aplicativo de locatário único, você pode usar o valor padrão, que está no formato api://<application-client-id>. Você também pode especificar um URI mais legível, como https://contoso.com/api com base em um dos domínios verificados para seu locatário. Para um aplicativo multilocatário, você deve fornecer um URI personalizado. Para saber mais sobre os formatos aceitos para URIs de ID de aplicativo, consulte a referência de práticas recomendadas de registros de aplicativos.

  13. Selecione Adicionar âmbito.

    1. Em Nome do escopo, digite user_impersonation.
    2. Em Quem pode consentir, selecione Administradores e usuários se quiser permitir que os usuários consintam com esse escopo.
    3. Nas caixas de texto, insira o nome e a descrição do escopo de consentimento que você deseja que os usuários vejam na página de consentimento. Por exemplo, insira o nome> do aplicativo do Access<.
    4. Selecione Adicionar escopo.

  14. (Opcional) Para criar um segredo do cliente:

    1. Na navegação à esquerda, selecione Certificados & segredos do>cliente Novo segredo do>cliente.
    2. Insira uma descrição e expiração e selecione Adicionar.
    3. No campo Valor, copie o valor secreto do cliente. Ele não será mostrado novamente quando você sair desta página.

  15. (Opcional) Para adicionar vários URLs de resposta, selecione Autenticação.

  16. Conclua a configuração do registro do aplicativo:

    Nenhuma outra etapa é necessária para um inquilino da força de trabalho.

Etapa 2: Habilitar a ID do Microsoft Entra em seu aplicativo do Serviço de Aplicativo

  1. Entre no portal do Azure e navegue até seu aplicativo.

  2. Na navegação à esquerda, selecione Autenticação>Adicionar provedor de>identidade Microsoft.

  3. Selecione o tipo de locatário do registro do aplicativo que você criou.

  4. Configure o aplicativo para usar o registro que você criou, usando as instruções para o tipo de locatário apropriado:

    Para Tipo de registro de aplicativo, escolha uma das seguintes opções:

    • Escolha um registro de aplicativo existente neste diretório: escolha um registro de aplicativo do locatário atual e reúna automaticamente as informações necessárias do aplicativo. O sistema tentará criar um novo segredo do cliente no registro do aplicativo e configurará automaticamente seu aplicativo para usá-lo. Um URL de emissor padrão é definido com base nos tipos de conta suportados configurados no registro do aplicativo. Se você pretende alterar esse padrão, consulte a tabela a seguir.
    • Forneça os detalhes de um registro de aplicativo existente: especifique os detalhes de um registro de aplicativo de outro locatário ou se sua conta não tiver permissão no locatário atual para consultar os registros. Para esta opção, você deve preencher manualmente os valores de configuração de acordo com a tabela a seguir.

    O ponto de extremidade de autenticação para um locatário da força de trabalho deve ser um valor específico para o ambiente de nuvem. Por exemplo, um locatário da força de trabalho no Azure global usaria "https://login.microsoftonline.com" como seu ponto de extremidade de autenticação. Anote o valor do ponto de extremidade de autenticação, pois ele é necessário para construir a URL do Emissor correta.

    Ao preencher os detalhes de configuração diretamente, use os valores coletados durante o processo de criação do registro do aplicativo:

    Campo Descrição
    ID da aplicação (cliente) Use a ID do aplicativo (cliente) do registro do aplicativo.
    Segredo do Cliente Use o segredo do cliente que você gerou no registro do aplicativo. Com um segredo do cliente, o fluxo híbrido é usado e o Serviço de Aplicativo retornará o acesso e atualizará os tokens. Quando o segredo do cliente não é definido, o fluxo implícito é usado e apenas um token de ID é retornado. Esses tokens são enviados pelo provedor e armazenados no repositório de tokens de autenticação do Serviço de Aplicativo.
    URL do emissor Use <authentication-endpoint>/<tenant-id>/v2.0e substitua< authentication-endpoint> pelo ponto de extremidade de autenticação determinado na etapa anterior para seu tipo de locatário e ambiente de nuvem, substituindo< também tenant-id> pelo Directory (tenant) ID no qual o registro do aplicativo foi criado. Para aplicativos que usam o Azure AD v1, omita /v2.0 na URL.

    Esse valor é usado para redirecionar os usuários para o locatário correto do Microsoft Entra, bem como para baixar os metadados apropriados para determinar as chaves de assinatura de token apropriadas e o valor de declaração do emissor de token, por exemplo. Qualquer configuração que não seja um ponto de extremidade específico do locatário será tratada como multilocatário. Em configurações multilocatário, nenhuma validação do emissor ou ID do locatário é executada pelo sistema, e essas verificações devem ser totalmente tratadas na lógica de autorização do seu aplicativo.
    Públicos de token permitidos Este campo é opcional. O ID do aplicativo (cliente) configurado é sempre implicitamente considerado como um público permitido. Se seu aplicativo representa uma API que será chamada por outros clientes, você também deve adicionar o URI de ID do aplicativo que você configurou no registro do aplicativo. Há um limite de 500 caracteres no total em toda a lista de públicos permitidos.

    O segredo do cliente será armazenado como uma configuração de aplicativo adesivo de slot chamada MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Você pode atualizar essa configuração posteriormente para usar referências do Cofre da Chave se desejar gerenciar o segredo no Cofre da Chave do Azure.

  5. Se este for o primeiro provedor de identidade configurado para o aplicativo, você também será solicitado com uma seção de configurações de autenticação do Serviço de Aplicativo. Caso contrário, você pode passar para a próxima etapa.

    Essas opções determinam como seu aplicativo responde a solicitações não autenticadas, e as seleções padrão redirecionarão todas as solicitações para entrar com esse novo provedor. Você pode alterar esse comportamento agora ou ajustar essas configurações posteriormente na tela principal Autenticação escolhendo Editar ao lado de Configurações de autenticação. Para saber mais sobre essas opções, consulte Fluxo de autenticação.

  6. Selecione Adicionar.

Agora você está pronto para usar a plataforma de identidade da Microsoft para autenticação em seu aplicativo. O provedor será listado na tela Autenticação . A partir daí, você pode editar ou excluir essa configuração do provedor.

Autorizar pedidos

Por padrão, a Autenticação do Serviço de Aplicativo lida apenas com a autenticação, determinando se o chamador é quem diz ser. A autorização, que determina se esse chamador deve ter acesso a algum recurso, é uma etapa extra além da autenticação. Você pode aprender mais sobre esses conceitos em Noções básicas de autorização de plataforma de identidade da Microsoft.

Seu aplicativo pode tomar decisões de autorização no código. A Autenticação do Serviço de Aplicativo fornece algumas verificações internas, que podem ajudar, mas elas podem não ser suficientes, por si só, para cobrir as necessidades de autorização do seu aplicativo.

Gorjeta

Os aplicativos multilocatários devem validar a ID do emissor e do locatário da solicitação como parte desse processo para garantir que os valores sejam permitidos. Quando a Autenticação do Serviço de Aplicativo é configurada para um cenário multilocatário, ela não valida de qual locatário a solicitação vem. Um aplicativo pode precisar ser limitado a locatários específicos, com base no fato de a organização ter se inscrito no serviço, por exemplo. Consulte as diretrizes multilocatárias da plataforma de identidade da Microsoft.

Executar validações a partir do código do aplicativo

Ao executar verificações de autorização no código do aplicativo, você pode aproveitar as informações de declarações que a Autenticação do Serviço de Aplicativo disponibiliza. O cabeçalho injetado x-ms-client-principal contém um objeto JSON codificado em Base64 com as declarações declaradas sobre o chamador. Por padrão, essas declarações passam por um mapeamento de declarações, portanto, os nomes das declarações nem sempre correspondem ao que você veria no token. Por exemplo, a declaração é mapeada tid para http://schemas.microsoft.com/identity/claims/tenantid em vez disso.

Você também pode trabalhar diretamente com o token de acesso subjacente a partir do cabeçalho injetado x-ms-token-aad-access-token .

Usar uma política de autorização interna

O registro do aplicativo criado autentica as solicitações de entrada para seu locatário do Microsoft Entra. Por padrão, ele também permite que qualquer pessoa dentro do locatário acesse o aplicativo, o que é bom para muitos aplicativos. No entanto, alguns aplicativos precisam restringir ainda mais o acesso tomando decisões de autorização. O código do aplicativo geralmente é o melhor lugar para lidar com a lógica de autorização personalizada. No entanto, para cenários comuns, a plataforma de identidade da Microsoft fornece verificações internas que você pode usar para limitar o acesso.

Esta seção mostra como habilitar verificações internas usando a API V2 de autenticação do Serviço de Aplicativo. Atualmente, a única maneira de configurar essas verificações internas é por meio de modelos do Azure Resource Manager ou da API REST.

Dentro do objeto API, a configuração do provedor de identidade Microsoft Entra tem uma validation seção que pode incluir um defaultAuthorizationPolicy objeto como na seguinte estrutura:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Property Description
defaultAuthorizationPolicy Um agrupamento de requisitos que devem ser atendidos para acessar o aplicativo. O acesso é concedido com base em uma lógica AND sobre cada uma de suas propriedades configuradas. Quando allowedApplications e allowedPrincipals estão configurados, a solicitação de entrada deve satisfazer ambos os requisitos para ser aceita.
allowedApplications Uma lista permitida de IDs de cliente de aplicativo de cadeia de caracteres que representam o recurso de cliente que está chamando o aplicativo. Quando essa propriedade é configurada como uma matriz não vazia, somente tokens obtidos por um aplicativo especificado na lista serão aceitos.

Esta política avalia a appid ou azp declaração do token de entrada, que deve ser um token de acesso. Consulte a referência de declarações da plataforma de identidade da Microsoft.
allowedPrincipals Um agrupamento de verificações que determina se a entidade representada pela solicitação de entrada pode acessar o aplicativo. A satisfação de é baseada em uma lógica OR sobre suas propriedades configuradasallowedPrincipals.
identities (em allowedPrincipals) Uma lista permitida de IDs de objeto de cadeia de caracteres que representam usuários ou aplicativos que têm acesso. Quando essa propriedade é configurada como uma matriz não vazia, o allowedPrincipals requisito pode ser satisfeito se o usuário ou aplicativo representado pela solicitação for especificado na lista. Há um limite de 500 caracteres no total em toda a lista de identidades.

Esta política avalia a oid declaração do token de entrada. Consulte a referência de declarações da plataforma de identidade da Microsoft.

Além disso, algumas verificações podem ser configuradas por meio de uma configuração de aplicativo, independentemente da versão da API que está sendo usada. A WEBSITE_AUTH_AAD_ALLOWED_TENANTS configuração do aplicativo pode ser configurada com uma lista separada por vírgulas de até 10 IDs de locatário (por exemplo, "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc") para exigir que o token de entrada seja de um dos locatários especificados, conforme especificado pela tid declaração. A WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL configuração do aplicativo pode ser configurada como "true" ou "1" para exigir que o token de entrada inclua uma oid declaração. Essa configuração é ignorada e tratada como verdadeira se allowedPrincipals.identities tiver sido configurada (uma vez que a declaração é verificada oid em relação a essa lista de identidades fornecida).

As solicitações que falharem nessas verificações internas recebem uma resposta HTTP 403 Forbidden .

Configurar aplicativos cliente para acessar seu Serviço de Aplicativo

Nas seções anteriores, você registrou seu Serviço de Aplicativo ou Função do Azure para autenticar usuários. Esta seção explica como registrar clientes nativos ou aplicativos daemon no Microsoft Entra ID para que eles possam solicitar acesso às APIs expostas pelo seu Serviço de Aplicativo em nome dos usuários ou de si mesmos, como em uma arquitetura de N camadas. Concluir as etapas nesta seção não é necessário se você deseja apenas autenticar usuários.

Aplicativo cliente nativo

Você pode registrar clientes nativos para solicitar acesso às APIs do aplicativo do Serviço de Aplicativo em nome de um usuário conectado.

  1. No menu do portal, selecione Microsoft Entra ID.

  2. Na navegação à esquerda, selecione Registos de>aplicações Novo registo.

  3. Na página Registar uma aplicação, introduza um Nome para o registo da sua aplicação.

  4. Em Redirecionar URI, selecione Cliente público (mobile & desktop) e digite a URL <app-url>/.auth/login/aad/callback. Por exemplo, https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Selecione Registar.

  6. Depois que o registro do aplicativo for criado, copie o valor da ID do aplicativo (cliente).

    Nota

    Para um aplicativo da Microsoft Store, use o SID do pacote como o URI.

  7. Na navegação à esquerda, selecione Permissões>de API Adicionar uma permissão>Minhas APIs.

  8. Selecione o registro do aplicativo que você criou anteriormente para seu aplicativo do Serviço de Aplicativo. Se não vir o registo da aplicação, certifique-se de que adicionou o âmbito user_impersonation em Criar um registo de aplicação no Microsoft Entra ID para a sua aplicação do Serviço de Aplicações.

  9. Em Permissões delegadas, selecione user_impersonation e, em seguida, selecione Adicionar permissões.

Agora você configurou um aplicativo cliente nativo que pode solicitar acesso ao seu aplicativo do Serviço de Aplicativo em nome de um usuário.

Aplicativo cliente Daemon (chamadas serviço-a-serviço)

Em uma arquitetura de N camadas, seu aplicativo cliente pode adquirir um token para chamar um Serviço de Aplicativo ou aplicativo de Função em nome do próprio aplicativo cliente (não em nome de um usuário). Este cenário é útil para aplicativos daemon não interativos que executam tarefas sem um usuário conectado. Ele usa a concessão de credenciais de cliente OAuth 2.0 padrão.

  1. No menu do portal, selecione Microsoft Entra ID.
  2. Na navegação à esquerda, selecione Registos de>aplicações Novo registo.
  3. Na página Registar uma aplicação, introduza um Nome para o registo da sua aplicação.
  4. Para um aplicativo daemon, você não precisa de um URI de redirecionamento para poder mantê-lo vazio.
  5. Selecione Registar.
  6. Depois que o registro do aplicativo for criado, copie o valor da ID do aplicativo (cliente).
  7. Na navegação à esquerda, selecione Certificados & segredos do>cliente Novo segredo do>cliente.
  8. Insira uma descrição e expiração e selecione Adicionar.
  9. No campo Valor, copie o valor secreto do cliente. Ele não será mostrado novamente quando você sair desta página.

Agora você pode solicitar um token de acesso usando a ID do cliente e o segredo do cliente definindo o resource parâmetro como o URI da ID do aplicativo de destino. O token de acesso resultante pode ser apresentado ao aplicativo de destino usando o cabeçalho de Autorização OAuth 2.0 padrão, e a autenticação do Serviço de Aplicativo validará e usará o token como de costume para indicar agora que o chamador (um aplicativo, neste caso, não um usuário) está autenticado.

No momento, isso permite que qualquer aplicativo cliente em seu locatário do Microsoft Entra solicite um token de acesso e se autentique no aplicativo de destino. Se você também quiser impor a autorização para permitir apenas determinados aplicativos cliente, deverá executar alguma configuração extra.

  1. Defina uma Função de Aplicativo no manifesto do registro do aplicativo que representa o aplicativo Serviço de Aplicativo ou Função que você deseja proteger.
  2. No registro do aplicativo que representa o cliente que precisa ser autorizado, selecione Permissões>de API Adicionar uma permissão>Minhas APIs.
  3. Selecione o registro do aplicativo que você criou anteriormente. Se não vir o registo da aplicação, certifique-se de que adicionou uma Função de Aplicação.
  4. Em Permissões de aplicativo, selecione a Função de Aplicativo criada anteriormente e selecione Adicionar permissões.
  5. Certifique-se de selecionar Conceder consentimento de administrador para autorizar o aplicativo cliente a solicitar a permissão.
  6. Semelhante ao cenário anterior (antes de quaisquer funções serem adicionadas), agora você pode solicitar um token de acesso para o mesmo destino resourcee o token de acesso incluirá uma roles declaração contendo as Funções de Aplicativo que foram autorizadas para o aplicativo cliente.
  7. No código do aplicativo Serviço de Aplicativo ou Função de destino, agora você pode validar se as funções esperadas estão presentes no token (isso não é executado pela autenticação do Serviço de Aplicativo). Para obter mais informações, consulte Acessar declarações de usuário.

Agora você configurou um aplicativo cliente daemon que pode acessar seu aplicativo do Serviço de Aplicativo usando sua própria identidade.

Melhores práticas

Independentemente da configuração utilizada para configurar a autenticação, as melhores práticas seguintes irão manter o inquilino e as aplicações mais seguros:

  • Configure cada aplicativo do Serviço de Aplicações com o seu próprio registo de aplicações no Microsoft Entra ID.
  • Atribua a cada aplicação do Serviço de Aplicações as suas próprias permissões e consentimento.
  • Evite a partilha de permissões entre ambientes através de registos de aplicações separados para blocos de implementação separados. Quando estiver a testar um novo código, esta prática pode ajudar a evitar problemas na aplicação de produção.

Migrar para o Microsoft Graph

Alguns aplicativos mais antigos também podem ter sido configurados com uma dependência do Azure AD Graph preterido, que está agendado para a desativação total. Por exemplo, o código do seu aplicativo pode ter chamado o Azure AD Graph para verificar a associação ao grupo como parte de um filtro de autorização em um pipeline de middleware. Os aplicativos devem ser movidos para o Microsoft Graph seguindo as orientações fornecidas pela ID do Microsoft Entra como parte do processo de descontinuação do Azure AD Graph. Ao seguir essas instruções, talvez seja necessário fazer algumas alterações na configuração da autenticação do Serviço de Aplicativo. Depois de adicionar permissões do Microsoft Graph ao registro do aplicativo, você pode:

  1. Atualize o URL do Emissor para incluir o sufixo "/v2.0", caso ainda não o faça.

  2. Remova solicitações de permissões do Azure AD Graph de sua configuração de entrada. As propriedades a serem alteradas dependem da versão da API de gerenciamento que você está usando:

    • Se você estiver usando a API V1 (/authsettings), isso estará na additionalLoginParams matriz.
    • Se você estiver usando a API V2 (/authsettingsV2), isso estará na loginParameters matriz.

    Você precisaria remover qualquer referência a "https://graph.windows.net", por exemplo. Isso inclui o resource parâmetro (que não é suportado pelo ponto de extremidade "/v2.0") ou quaisquer escopos que você está solicitando especificamente que são do Azure AD Graph.

    Você também precisaria atualizar a configuração para solicitar as novas permissões do Microsoft Graph configuradas para o registro do aplicativo. Você pode usar o escopo .default para simplificar essa configuração em muitos casos. Para fazer isso, adicione um novo parâmetro scope=openid profile email https://graph.microsoft.com/.defaultde entrada .

Com essas alterações, quando a Autenticação do Serviço de Aplicativo tentar entrar, ela não solicitará mais permissões para o Azure AD Graph e, em vez disso, obterá um token para o Microsoft Graph. Qualquer uso desse token do código do seu aplicativo também precisaria ser atualizado, de acordo com as orientações fornecidas pelo Microsoft Entra ID.

Passos seguintes