Configurar seu aplicativo do Serviço de Aplicativo ou do Azure Functions para usar o logon do Microsoft Entra

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

Este artigo mostra como configurar a autenticação para o Serviço de Aplicativo do Azure ou o Azure Functions de modo que seu aplicativo conecte os usuários com a Plataforma de Identidade da Microsoft (Microsoft Entra ID) como o provedor de autenticação.

O recurso de 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 crie separadamente.

Observação

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

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

Use esta 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 que ele for criado.

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

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

  3. Selecione Microsoft na lista suspensa de provedores de identidade. A opção para criar um registro é selecionada por padrão. Você pode alterar o nome do registro ou os tipos de conta com suporte.

    Um segredo do cliente será criado e armazenado como uma configuração de aplicativo de slot fixo chamada MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Você poderá atualizar essa configuração posteriormente para usar referências do Key Vault se quiser gerenciar o segredo no Azure Key Vault.

  4. Se este for o primeiro provedor de identidade configurado para o aplicativo, você também receberá um prompt da seção de Configurações de autenticação do Serviço de Aplicativo. Caso contrário, passe para a próxima etapa.

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

  5. (Opcional) Selecione Avançar: Permissões e adicione quaisquer permissões do Microsoft Graph necessárias para o aplicativo. Eles serão adicionados ao registro do aplicativo, mas você também poderá 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 de Autenticação. A partir daí, você pode editar ou excluir essa configuração de provedor.

Para obter um exemplo de como configurar o logon do Microsoft Entra para um aplicativo Web que acessa o Armazenamento do Azure e o Microsoft Graph, confira 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 o uso de 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ê quer 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 registro não está disponível para nuvens governamentais.

Etapa 1: Criar um registro de aplicativo no Microsoft Entra ID 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 ao configurar a autenticação Serviço de Aplicativo:

  • ID do Cliente
  • ID do locatário
  • Segredo do cliente (opcional, mas recomendado)
  • URI da ID de 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 (versão prévia). Use as guias abaixo para selecionar o conjunto certo de instruções para seu cenário.

Para registrar o aplicativo, siga estas etapas:

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

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

    No menu do portal, selecione Microsoft Entra ID. Se o locatário que você está usando for diferente do que você usa para configurar o aplicativo 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 Primário.

  4. Na área de navegação à esquerda, selecione Registros de aplicativo>Novo registro.

  5. Na página Registrar um aplicativo, insira um Nome para o registro do seu aplicativo.

  6. Em Tipos de conta com suporte, selecione o tipo de conta que pode acessar este aplicativo.

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

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

  10. Em Concessão implícita e fluxos híbridos, habilite tokens de ID para permitir as entradas de usuário do OpenID Connect a partir do Serviço de Aplicativo. Selecione Salvar.

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

  12. Na área de navegação à esquerda, selecione Expor um API>Configurar>Salvar. Esse valor identifica exclusivamente o aplicativo quando ele é usado como um recurso, permitindo que tokens sejam solicitados para conceder o acesso. Ele é usado como um prefixo para os escopos que você cria.

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

  13. Selecione Adicionar um escopo.

    1. Em Nome do escopo, digite user_impersonation.
    2. Em Quem pode dar consentimento, selecione Administradores e usuários se você quiser permitir que os usuários consintam com este escopo.
    3. Nas caixas de texto, insira o nome do escopo de consentimento e a descrição que você deseja que os usuários vejam na página de consentimento. Por exemplo, insira Acessar <nome-do-aplicativo> .
    4. Selecione Adicionar escopo.
  14. (Opcional) Para criar um segredo do cliente:

    1. Na navegação à esquerda, selecione Certificados e segredos Segredos do>cliente Novo segredo do>cliente.
    2. Insira uma descrição, uma expiração, e selecione Adicionar.
    3. No campo Valor, copiar o valor do segredo do cliente. Ele não será mostrado novamente quando você navegar para fora desta página.
  15. (Opcional) Para adicionar várias URLs de resposta, selecione Autenticação.

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

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

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

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

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

  3. Selecione o Tipo de locatário do registro de 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 o 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 sobre o aplicativo. O sistema tentará criar um novo segredo do cliente no registro do aplicativo e configurará automaticamente seu aplicativo para usá-lo. Uma URL do emissor padrão é definida com base nos tipos de conta com suporte configurados no registro do aplicativo. Se você pretende alterar esse padrão, confira 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 essa 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 de 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 correta do Emissor.

    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 do aplicativo (cliente) Use a ID do aplicativo (cliente) do registro do aplicativo.
    Segredo do cliente Use o segredo do cliente gerado no registro do aplicativo. Com um segredo do cliente, o fluxo híbrido é usado, e o Serviço de Aplicativo retornará tokens de acesso e de atualização. Quando o segredo do cliente não estiver definido, será usado o fluxo implícito e apenas um token de ID retornará. Esses tokens são enviados pelo provedor e armazenados no repositório de tokens da Autenticação do Serviço de Aplicativo.
    URL do emissor Use <authentication-endpoint>/<tenant-id>/v2.0, e substitua <authentication-endpoint>> pelo ponto de extremidade de autenticação que você determinou na etapa anterior pelo tipo de locatário e ambiente de nuvem, substituindo também <tenant-id>> pela ID do Directory (locatário) 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 do token, por exemplo. Qualquer configuração diferente de um ponto de extremidade específico do locatário será tratada como multilocatário. Em configurações multilocatários, nenhuma validação da ID do emissor ou do locatário é executada pelo sistema e essas verificações devem ser totalmente tratadas na lógica de autorização do aplicativo.
    Audiências de token permitidas Esse campo é opcional. A ID do Aplicativo (cliente) configurada é sempre implicitamente considerada uma audiência permitida. Se o aplicativo representar uma API que será chamada por outros clientes, você também deverá adicionar o URI da ID do Aplicativo configurado no registro do aplicativo. Há um limite total de 500 caracteres na lista de públicos permitidos.

    O segredo do cliente será armazenado como uma configuração de aplicativo de slot fixo chamadaMICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Você poderá atualizar essa configuração posteriormente para usar referências do Key Vault se quiser gerenciar o segredo no Azure Key Vault.

  5. Se este for o primeiro provedor de identidade configurado para o aplicativo, você também receberá um prompt da seção de Configurações de autenticação do Serviço de Aplicativo. Caso contrário, passe para a próxima etapa.

    Essas opções determinam como o aplicativo responde a solicitações não autenticadas e como as seleções padrão redirecionarão todas as solicitações para conectar esse novo provedor. Você pode alterar e personalizar esse comportamento agora ou ajustar essas configurações posteriormente na tela principal de Autenticação escolhendo Editar ao lado de Configurações de autenticação. Para saber mais sobre essas opções, confira 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 de Autenticação. A partir daí, você pode editar ou excluir essa configuração de provedor.

Autorizar solicitações

Por padrão, a Autenticação do Serviço de Aplicativo somente trata da autenticação, determinando se o chamador é quem ele diz ser. A autorização, determinando se o chamador deve ter acesso a algum recurso, é uma etapa extra além da autenticação. Você pode aprender mais sobre estes conceitos a partir de noções básicas de autorização na plataforma de identidade da Microsoft.

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

Dica

Os aplicativos multi-locatários devem validar a ID do emissor e do locatário da solicitação como parte deste processo para garantir que os valores sejam permitidos. Quando a Autenticação do Serviço de Aplicativo é configurada para um cenário multi-locatá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 em se a organização se inscreveu para o serviço, por exemplo. Consulte as Diretrizes de multi-locatário na plataforma de identidade da Microsoft.

Realizar validações a partir do código de aplicativo

Quando você realiza verificações de autorização em seu 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 Base64 com as declarações invocadas sobre o chamador. Por padrão, estas declarações passam por um mapeamento de declarações, de modo que os nomes das declarações nem sempre correspondem ao que você veria no token. Por exemplo, a declaração tid é mapeada 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 x-ms-token-aad-access-token injetado.

Usar uma política de autorização integrada

O registro de aplicativo criado autentica as solicitações recebidas para seu locatário do Microsoft Entra. Por padrão, ele também permite que qualquer pessoa dentro do locatário tenha acesse ao 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. Entretanto, para cenários comuns, a plataforma de identidade da Microsoft fornece verificações integradas 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 de API, a configuração do provedor de identidade do Microsoft Entra tem uma seção validation que pode incluir um objeto defaultAuthorizationPolicy como na seguinte estrutura:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Propriedade Descrição
defaultAuthorizationPolicy Uma série de requisitos que precisam ser atendidos para acessar o aplicativo. O acesso é concedido com base em um AND lógico sobre cada uma de suas propriedades configuradas dele. Quando allowedApplications e allowedPrincipals estão configurados, a solicitação de entrada precisa atender aos dois requisitos para ser aceita.
allowedApplications Uma lista de permitidos de IDs de cliente de cadeia de caracteres do aplicativo que representam o recurso do cliente que está chamando o aplicativo. Quando essa propriedade é configurada como uma matriz não vazia, somente os tokens obtidos por um aplicativo especificado na lista são aceitos.

Essa política avalia a declaração appid ou azp do token de entrada, que precisa ser um token de acesso. Consulte a referência de declarações da plataforma de identidade da Microsoft.
allowedPrincipals Uma série de verificações que determinam se a entidade de segurança representada pela solicitação de entrada pode acessar o aplicativo. A satisfação de allowedPrincipals é baseada em um OR lógico aplicado sobre as propriedades configuradas dele.
identities (em allowedPrincipals) Uma lista de permitidos 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 requisito allowedPrincipals pode ser atendido se o usuário ou aplicativo representado pela solicitação é especificado na lista. Há um limite total de 500 caracteres na lista de públicos permitidos.

Essa política avalia a declaração oid 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 através de uma configuração de aplicativo, independentemente da versão da API que está sendo usada. A configuração do aplicativo WEBSITE_AUTH_AAD_ALLOWED_TENANTS 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, como especificado pela declaração tid. A configuração do aplicativo WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL pode ser configurada para "true" ou "1" para exigir que o token de entrada inclua uma declaração oid. Esta configuração é ignorada e tratada como true se allowedPrincipals.identities tiver sido configurado (uma vez que a declaração oid é verificada em relação a esta lista de identidades fornecida).

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

Configurar aplicativos do cliente para acessar o Serviço de Aplicativo

Nas seções anteriores, você registrou seu Serviço de Aplicativo ou Função do Azure para autenticar os 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 por seu Serviço de Aplicativo em nome dos usuários ou deles próprios, como em uma arquitetura de N camadas. Se você quiser apenas autenticar usuários, não será necessário concluir as etapas desta seção.

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 área de navegação à esquerda, selecione Registros de aplicativo>Novo registro.

  3. Na página Registrar um aplicativo, insira um Nome para o registro do seu aplicativo.

  4. Em URI de redirecionamento, selecione Cliente público (móvel e área de trabalho) e digite a URL <app-url>/.auth/login/aad/callback. Por exemplo, https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Selecione Registrar.

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

    Observação

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

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

  8. Selecione o registro de aplicativo que você criou anteriormente para seu aplicativo do Serviço de Aplicativo. Se você não vir o registro do aplicativo, certifique-se de ter adicionado o escopo user_impersonation em Criar um registro de aplicativo no Microsoft Entra ID para o aplicativo do Serviço de Aplicativo.

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

Você já 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 de 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ções em nome do próprio aplicativo cliente (não em nome de um usuário). Esse cenário é útil para aplicativos daemon não interativos que executam tarefas sem um usuário conectado. Ele usa a concessão das credenciais de cliente padrão do OAuth 2.0.

  1. No menu do portal, selecione Microsoft Entra ID.
  2. Na área de navegação à esquerda, selecione Registros de aplicativo>Novo registro.
  3. Na página Registrar um aplicativo, insira um Nome para o registro do seu aplicativo.
  4. Em um aplicativo daemon, você não precisa de um URI de redirecionamento para que possa mantê-lo vazio.
  5. Selecione Registrar.
  6. Depois que o registro do aplicativo for criado, copie o valor da ID do aplicativo (cliente) .
  7. Na navegação à esquerda, selecione Certificados e segredos Segredos do>cliente Novo segredo do>cliente.
  8. Insira uma descrição, uma expiração, e selecione Adicionar.
  9. No campo Valor, copiar o valor do segredo do cliente. Ele não será mostrado novamente quando você navegar para fora desta página.

Agora você pode solicitar um token de acesso usando a ID e o segredo do cliente, definindo o parâmetro resource como o URI da ID do aplicativo de destino. O token de acesso resultante pode então 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 no seu locatário do Microsoft Entra solicite um token de acesso e faça a autenticação no aplicativo de destino. Se você também quiser impor autorização para permitir apenas determinados aplicativos cliente, deverá executar algumas configurações extras.

  1. Defina uma função de aplicativo no manifesto do registro do aplicativo que representa o Serviço de Aplicativo ou o aplicativo de Funções que você deseja proteger.
  2. No registro do aplicativo representando o cliente que precisa ser autorizado, selecione Permissões da API>Adicionar uma permissão>Minhas APIs.
  3. Selecione o registro de aplicativo que você criou anteriormente. Se você não vir o registro do aplicativo, verifique se adicionou uma Função de Aplicativo.
  4. Em Permissões de aplicativo, selecione a Função de Aplicativo que você criou anteriormente e, em seguida, selecione Adicionar permissões.
  5. Selecione Conceder consentimento de administração para autorizar o aplicativo cliente a solicitar a permissão.
  6. Semelhante ao cenário anterior (antes de qualquer função ter sido adicionada), agora você pode solicitar um token de acesso para o mesmo resource de destino, e o token de acesso incluirá uma declaração de roles contendo as Funções de Aplicativo autorizadas para o aplicativo cliente.
  7. Dentro do Serviço de Aplicativo de destino ou do código do Aplicativo de Funções, você pode agora validar que as funções esperadas estão presentes no token (isto não é realizado pela autenticação do Serviço de Aplicativo). Para mais informações, consulte Acessar declarações de usuário.

Você já configurou um aplicativo cliente daemon que pode acessar seu aplicativo do Serviço de Aplicativo usando uma identidade própria.

Práticas recomendadas

Independentemente da configuração usada para definir a autenticação, as seguintes melhores práticas manterão seu locatário e seus aplicativos mais seguros:

  • Configure cada aplicativo do Serviço de Aplicativo com seu próprio registro no Microsoft Entra ID.
  • Dê a cada aplicativo do Serviço de Aplicativo suas próprias permissões e consentimento.
  • Evite o compartilhamento de permissão entre ambientes usando registros de aplicativo separados para slots de implantação separados. Essa prática pode ajudar a evitar problemas que afetam o aplicativo de produção durante o teste do novo código.

Migre 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á programado para ser totalmente desativado. Por exemplo, o código do seu aplicativo pode ter chamado o Azure AD Graph para verificar a associação de grupo como parte de um filtro de autorização em um pipeline de middleware. Os aplicativos devem migrar para o Microsoft Graph seguindo as diretrizes fornecidas pelo Microsoft Entra ID como parte do processo de substituição do Azure AD Graph. Ao seguir essas instruções, talvez seja necessário fazer algumas alterações em sua configuração de autenticação do Serviço de Aplicativo. Depois de adicionar as permissões do Microsoft Graph ao registro do seu aplicativo, você poderá:

  1. Atualizar o URL do emissor para incluir o sufixo "/v2.0", caso ainda não o tenha feito.

  2. Remover as solicitações de permissões do Azure AD Graph de sua configuração de logon. 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 matriz additionalLoginParams.
    • Se você estiver usando a API V2 (/authsettingsV2), isso estará na matriz loginParameters.

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

    Também seria necessário atualizar a configuração para solicitar as novas permissões do Microsoft Graph que você definiu 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 de logon scope=openid profile email https://graph.microsoft.com/.default.

Com essas alterações, quando a Autenticação do Serviço de Aplicativo tenta fazer logon, 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 aplicativo também precisaria ser atualizado, de acordo com as diretrizes fornecidas pelo Microsoft Entra ID.

Próximas etapas