Partilhar via

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

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

Este artigo mostra como configurar a autenticação para o Serviço de Aplicação do Azure ou Azure Functions para que a sua aplicação inicie sessão para utilizadores com a plataforma de identidade da Microsoft (Microsoft Entra) como o provedor de autenticação.

Escolha um locatário para seu aplicativo e seus usuários

Antes que a sua aplicação possa autenticar utilizadores, precisa de a registar num tenant de trabalho ou num tenant externo. Se você estiver disponibilizando seu aplicativo para funcionários ou convidados de negócios, registre seu aplicativo em um locatário do mercado de trabalho. Se o seu aplicativo for para consumidores e clientes empresariais, registre-o em um locatário externo.

  1. Entre no portal do Azure e vá para seu aplicativo.

  2. No menu esquerdo da sua aplicação, selecione Definições>Autenticação, e, em seguida, selecione Adicionar fornecedor de identidade.

  3. Na página Adicionar um provedor de identidade, selecione Microsoft como o valor do provedor de identidade para iniciar sessão com as identidades Microsoft e Microsoft Entra.

  4. Em Escolha um locatário para seu aplicativo e seus usuários, selecione:

    • Configuração da força de trabalho (locatário atual) para funcionários e hóspedes de negócios
    • Configuração externa para consumidores e clientes empresariais

Escolha o registo da aplicação

O recurso de autenticação do Serviço de Aplicativo pode criar automaticamente um registro de aplicativo para você. Ou, você pode usar um registro que você ou um administrador de diretório cria separadamente.

Crie um novo registro de aplicativo automaticamente, a menos que você precise criar um registro de aplicativo separadamente. Você pode personalizar o registro do aplicativo no centro de administração do Microsoft Entra mais tarde, se desejar.

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 registo de aplicação de um tenant do Microsoft Entra diferente daquele que contém o seu aplicativo. Este é sempre o caso se você selecionou Configuração externa quando escolheu um locatário.
  • A opção de criar um novo registro não está disponível para nuvens governamentais.

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

  1. Selecione Criar novo registro de aplicativo.

  2. Em Nome, insira o nome do novo registro do aplicativo.

  3. Selecione o valor Tipo de conta suportado :

    • Inquilino atual - Inquilino único. Apenas contas neste diretório organizacional. Todas as contas de usuário e convidado em seu diretório podem usar seu aplicativo ou API. Utilize esta opção se o seu público-alvo for interno à sua organização.
    • Qualquer diretório Microsoft Entra - Multitenant. Contas em qualquer diretório de uma organização. Todos os usuários com uma conta corporativa ou de estudante da Microsoft podem usar seu aplicativo ou API. Estas contas incluem escolas e empresas que utilizam o Office 365. Use esta opção se o seu público-alvo forem clientes empresariais ou educacionais e para permitir a multitenância.
    • Qualquer diretório do Microsoft Entra e contas pessoais da Microsoft. Contas em qualquer diretório organizacional e contas pessoais da Microsoft (por exemplo, Skype ou Xbox). Todos os utilizadores com uma conta escolar ou profissional, ou uma conta Microsoft pessoal, podem utilizar a sua aplicação ou API. Inclui escolas e empresas que utilizam o Office 365, juntamente com contas pessoais que são utilizadas para iniciar sessão em serviços como a Xbox e o Skype. Use essa opção para direcionar o conjunto mais amplo de identidades da Microsoft e habilitar a multilocação.
    • Apenas contas pessoais da Microsoft. Contas pessoais que são utilizadas para iniciar sessão em serviços como a Xbox e o Skype. Use esta opção para alcançar o conjunto mais amplo de identidades da Microsoft.

Você pode alterar o nome do registro ou os tipos de conta suportados mais tarde, se desejar.

Um segredo de cliente é criado como uma configuração de aplicação persistente chamada . Se quiser gerenciar o segredo no Cofre da Chave do Azure, você pode atualizar essa configuração posteriormente para usar as referências do Cofre da Chave. Como alternativa, você pode alterar isso para usar uma identidade em vez de um segredo do cliente. O suporte para o uso de uma identidade está atualmente em pré-visualização.

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

Para usar um registro existente, selecione:

  • Escolha um registro de aplicativo existente neste diretório. Em seguida, selecione um registro de aplicativo na lista suspensa.

  • Forneça os detalhes de um registro de aplicativo existente. Em seguida, forneça:

    • ID do aplicativo (cliente).

    • Segredo do cliente (recomendado). Um valor secreto que o aplicativo usa para provar sua identidade quando solicita um token. Este valor é guardado na configuração da sua aplicação como uma definição de aplicação do tipo "slot-sticky" chamada MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Se o segredo do cliente não estiver definido, as operações de entrada do serviço usarão o fluxo de concessão implícita do OAuth 2.0, que não recomendamos.

      Você também pode configurar o aplicativo para usar uma identidade em vez de um segredo do cliente. O suporte para o uso de uma identidade está atualmente em pré-visualização.

    • URL do emissor. Este URL assume a forma de <authentication-endpoint>/<tenant-id>/v2.0. Substitua <authentication-endpoint> pelo valor do ponto de extremidade de autenticação específico do ambiente de nuvem. Por exemplo, um arrendatário de recursos humanos no Azure global usaria https://sts.windows.net como o ponto de extremidade de autenticação.

Se você precisar criar manualmente um registro de aplicativo em um locatário da força de trabalho, consulte Registrar um aplicativo com a plataforma de identidade da Microsoft. Ao passar pelo processo de registro, certifique-se de anotar o ID do aplicativo (cliente) e os valores secretos do cliente.

Durante o processo de registro, na seção Redirecionar URIs , selecione Web para plataforma e insira um URI de redirecionamento. Por exemplo, digite https://contoso.azurewebsites.net/.auth/login/aad/callback.

Agora, modifique o registro do aplicativo:

  1. No painel esquerdo, selecione Expor uma API>Adicionar>Salvar. Esse valor identifica exclusivamente o aplicativo quando ele é usado como um recurso, o que permite que tokens que concedem acesso sejam solicitados. O valor é 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 obter mais informações sobre formatos aceitos para URIs de ID de aplicativo, consulte Práticas recomendadas de segurança para propriedades de aplicativo no Microsoft Entra ID.

  2. Selecione Adicionar um escopo e, em seguida:

    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. Insira o nome do escopo de consentimento. Insira uma descrição que você deseja que os usuários vejam na página de consentimento. Por exemplo, insira o nome do aplicativodo Access.
    4. Selecione Adicionar escopo.

  3. (Recomendado) Crie uma asserção de cliente para o aplicativo. Para criar um segredo do cliente:

    1. No painel esquerdo, selecione Certificados & segredos do> clienteNovo segredo> cliente.
    2. Introduza uma descrição e expiração e, em seguida, selecione Adicionar.
    3. No campo Valor, copie o valor secreto do cliente. Depois que você se afastar desta página, ela não aparecerá novamente.

    Você também pode configurar o aplicativo para usar uma identidade em vez de um segredo do cliente. O suporte para o uso de uma identidade está atualmente em pré-visualização.

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

Configurar verificações adicionais

Verificações adicionais determinam quais solicitações têm permissão para acessar seu aplicativo. Você pode personalizar esse comportamento agora ou ajustar essas configurações posteriormente na página principal Autenticação , selecionando Editar ao lado de Configurações de autenticação.

Para Requisito de aplicativo cliente, escolha se:

  • Permitir solicitações somente a partir deste aplicativo em si.
  • Permitir solicitações de aplicativos cliente específicos.
  • Permitir solicitações de qualquer aplicativo (não recomendado).

Para Requisito de identidade, escolha se:

  • Permitir solicitações de qualquer identidade.
  • Permitir solicitações de identidades específicas.

Para Requisito de locatário, escolha se:

  • Permitir apenas solicitações do locatário emissor.
  • Permitir solicitações de locatários específicos.
  • Use restrições padrão com base no emissor.

Seu aplicativo ainda pode precisar tomar outras decisões de autorização no código. Para obter mais informações, consulte Usar uma política de autorização interna mais adiante neste artigo.

Configurar definições de autenticação

As configurações de autenticação determinam como seu aplicativo responde a solicitações não autenticadas. As seleções padrão redirecionam todas as solicitações para entrar com esse novo provedor. Você pode personalizar esse comportamento agora ou ajustar essas configurações posteriormente na página principal Autenticação , selecionando Editar ao lado de Configurações de autenticação. Para obter mais informações, consulte Fluxo de autenticação.

Em Restringir acesso, decida se:

  • Requer autenticação.
  • Permitir acesso não autenticado.

Para solicitações não autenticadas, escolha as opções de erro:

  • HTTP 302 Found redirect: recomendado para sites
  • HTTP 401 Unauthorized: recomendado para APIs
  • HTTP 403 Forbidden
  • HTTP 404 Not found

Selecione Loja de Tokens (recomendado). O repositório de tokens coleta, armazena e atualiza tokens para seu aplicativo. Você pode desabilitar esse comportamento mais tarde se seu aplicativo não precisar de tokens ou se precisar otimizar o desempenho.

Adicionar o provedor de identidade

Se você selecionou a configuração da força de trabalho, poderá selecionar Avançar: Permissões e adicionar as permissões do Microsoft Graph de que o aplicativo precisa. Essas permissões são adicionadas ao registro do aplicativo, mas você também pode alterá-las mais tarde. Se você selecionou a configuração externa, poderá adicionar permissões do Microsoft Graph posteriormente.

  • Selecione Adicionar.

Agora você está pronto para usar a plataforma de identidade da Microsoft para autenticação em seu aplicativo. O provedor está listado na página 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 Adicionar autenticação de aplicação Web à sua aplicação.

Autorizar pedidos

Por padrão, o Serviço de Aplicativo lida apenas com a autenticação. Determina se o autor da chamada é quem diz ser. A autorização, que determina se esse chamador deve ter acesso a algum recurso, é um passo além da autenticação. Para obter mais informações, consulte Noções básicas de autorização.

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 sozinhas podem não ser suficientes para cobrir as necessidades de autorização do seu aplicativo. As seções a seguir abordam esses recursos.

Gorjeta

Os aplicativos multilocatários devem validar o ID do emissor e o ID 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 Atualize o seu código para lidar com vários valores de emissor.

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

Ao realizar verificações de autorização no código da aplicação, pode usar as informações de reivindicações que a autenticação do serviço de aplicativo disponibiliza. Para mais informações, consulte Aceder a declarações de utilizador no código da aplicação.

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 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 injetado x-ms-token-aad-access-token .

Usar uma política de autorização interna

O registo da aplicação criada autentica as solicitações de entrada para a sua entidade Microsoft Entra. Por padrão, ele também permite que qualquer pessoa dentro do locatário acesse o aplicativo. Essa abordagem é boa para muitos aplicativos. 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 é usando modelos do Azure Resource Manager ou a 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, conforme mostrado na estrutura a seguir:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Propriedade Descrição
defaultAuthorizationPolicy Um grupo de requisitos que devem ser atendidos para acessar o aplicativo. O acesso é concedido com base em um raciocínio lógico AND em relação a cada uma de suas propriedades configuradas. Quando allowedApplications e allowedPrincipals são ambos configurados, a solicitação de entrada deve satisfazer ambos os requisitos para ser aceita.
allowedApplications Uma lista de permissão de IDs de cliente em formato de cadeia de caracteres que representam o recurso de cliente que chama o aplicativo. Quando essa propriedade é configurada como uma matriz não vazia, somente tokens obtidos por um aplicativo especificado na lista são aceitos.

Esta política avalia a appid ou azp declaração do token de entrada, que deve ser um token de acesso. Consulte Declarações de carga útil.
allowedPrincipals Um grupo de verificações que determina se o principal que a solicitação recebida representa pode aceder à aplicação. A satisfação de allowedPrincipals é baseada numa lógica OR acerca das suas propriedades configuradas.
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 que a solicitação representa for especificado na lista. Há um limite de 500 caracteres (total) na lista de identidades.

Esta política avalia a oid reivindicação do token recebido. Consulte Declarações de carga útil.

Além disso, você pode configurar algumas verificações por meio de uma configuração de aplicativo, independentemente da versão da API que estiver usando. Você pode definir a configuração do aplicativo com uma lista separada por vírgulas WEBSITE_AUTH_AAD_ALLOWED_TENANTS de até 10 IDs de locatário, por exemplo, aaaabbbb-0000-cccc-1111-dddd2222eeee. Essa configuração pode exigir que o token de entrada seja de um dos locatários especificados, conforme especificado pela tid declaração.

Você pode configurar a definição da aplicação WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL para true ou 1, de modo a exigir que o token de entrada inclua um claim oid. Se configurou allowedPrincipals.identities, essa configuração será ignorada e tratada como verdadeira porque oid é verificado através desta lista fornecida de identidades.

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

Usar uma identidade gestionada em vez de um segredo (pré-visualização)

Em vez de configurar um segredo do cliente para o registro do aplicativo, você pode configurar um aplicativo para confiar em uma identidade gerenciada (visualização). Usar uma identidade em vez de um segredo significa que você não precisa gerenciar um segredo. Você não tem eventos de expiração secretos para lidar e não tem o mesmo nível de risco associado a possivelmente divulgar ou vazar esse segredo.

A identidade permite criar uma credencial de identidade federada, que pode ser usada em vez de um segredo do cliente como uma declaração de cliente. Essa abordagem está disponível apenas para configurações de força de trabalho. O recurso de autenticação integrado atualmente oferece suporte a credenciais de identidade federada em versão de pré-visualização.

Você pode usar as etapas nesta seção para configurar seu Serviço de Aplicativo ou recurso do Azure Functions para usar esse padrão. As etapas aqui pressupõem que você já configurou um registro de aplicativo usando um dos métodos suportados e que já tem um segredo definido.

  1. Crie um recurso de identidade gerenciado atribuído pelo usuário de acordo com estas instruções.

  2. Atribua essa identidade ao seu Serviço de Aplicativo ou recurso do Azure Functions.

    Importante

    A identidade gerenciada atribuída ao usuário que você cria só deve ser atribuída ao Serviço de Aplicativo ou ao aplicativo Azure Functions por meio desse registro. Se você atribuir a identidade a outro recurso, estará concedendo a esse recurso acesso desnecessário ao registro do seu aplicativo.

  3. Anote os valores de ID do objeto e ID do cliente da identidade gerenciada. Você precisará da ID do objeto para criar uma credencial de identidade federada na próxima etapa. Você usará o ID do cliente da identidade gerenciada em uma etapa posterior.

  4. Siga as instruções do Microsoft Entra ID para configurar uma credencial de identidade federada em um aplicativo existente. Essas instruções também incluem seções para atualizar o código do aplicativo, que você pode ignorar.

  5. Adicione uma nova configuração de aplicativo chamada OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Defina o seu valor para o valor do ID do cliente da identidade gerida, obtido num passo anterior. Não use o ID de cliente do registo da sua aplicação. Certifique-se de marcar esta configuração do aplicativo como slot-sticky.

  6. Nas configurações de autenticação internas para o recurso do aplicativo, defina Nome da configuração Segredo do cliente como OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

    Para fazer essa alteração usando o portal do Azure:

    1. Volte ao seu recurso Serviço de Aplicativo ou Azure Functions e selecione a guia Autenticação .
    2. Na seção Provedor de identidade , para a entrada Microsoft , selecione o ícone na coluna Editar .
    3. Na caixa de diálogo Editar provedor de identidade, abra a lista suspensa para Nome da definição do segredo do cliente e selecione OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.
    4. Selecione Guardar.

    Para fazer essa alteração usando a API REST:

    • Defina a propriedade clientSecretSettingName como OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Você pode encontrar esta propriedade em properties>identityProviders>azureActiveDirectory>registration.

  7. Verifique se o aplicativo funciona como esperado. Você deve ser capaz de executar com êxito uma nova ação de entrada.

Quando estiver satisfeito com o comportamento usando uma identidade gerenciada, remova o segredo existente:

  1. Certifique-se de que o código do aplicativo não dependa da configuração do aplicativo. Se isso acontecer, siga as instruções para atualizar o código do aplicativo para solicitar um token de acesso.

  2. Remova a configuração do aplicativo que anteriormente mantinha seu segredo. O nome desta configuração de aplicativo é o valor anterior do nome da configuração de segredo do cliente , antes de defini-lo como OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

  3. Inicie sessão no centro de administração do Microsoft Entra utilizando o tenant que contém o registo da aplicação. Vá para o registro do aplicativo novamente.

  4. Em Certificados & segredos, selecione Segredos do cliente e remova o segredo do cliente.

Seu aplicativo agora está configurado para usar a autenticação de ID do Microsoft Entra sem segredos.

Configurar aplicativos cliente para acessar o Serviço de Aplicativo

Nas seções anteriores, você registrou seu Serviço de Aplicativo ou aplicativo Azure Functions para autenticar usuários. As seções a seguir explicam como registrar clientes nativos ou aplicativos daemon no Microsoft Entra. Esses clientes ou aplicativos podem solicitar acesso a APIs expostas pelo Serviço de Aplicativo em nome dos usuários ou de si mesmos, como em uma arquitetura de N camadas. Se você quiser apenas autenticar usuários, as etapas nas seções a seguir não são necessárias.

Aplicativo cliente nativo

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

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

  2. No painel esquerdo, selecione Gerenciar>registros de aplicativos. Em seguida, selecione Novo registro.

  3. No painel Registrar um aplicativo , em Nome, insira um nome para o registro do aplicativo.

  4. Em Redirecionar URI, selecione Cliente público/nativo (mobile & desktop) e insira a URL de redirecionamento. Por exemplo, digite https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Selecione Registar.

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

    Nota

    Para uma aplicação da Microsoft Store, use o SID do pacote como o URI.

  7. No painel esquerdo, selecione Gerenciar>permissões de API. Em seguida, selecione 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 não vir o registo da aplicação, certifique-se de que adiciona a permissão user_impersonation no registo da aplicação.

  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.

Aplicação cliente Daemon (chamadas de serviço para serviço)

Em uma arquitetura de N camadas, seu aplicativo cliente pode adquirir um token para chamar um Serviço de Aplicativo ou aplicativo do Azure Functions 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. Para obter mais informações, consulte Plataforma de identidade da Microsoft e o fluxo de credenciais do cliente OAuth 2.0.

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

  2. No painel esquerdo, selecione Gerenciar>registros de aplicativos. Em seguida, selecione Novo registro.

  3. No painel Registrar um aplicativo , em Nome, insira um nome para o registro do aplicativo.

  4. Para um aplicativo daemon, você não precisa de um URI de redirecionamento, para que possa manter a caixa URI de redirecionamento vazia.

  5. Selecione Registar.

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

  7. No painel esquerdo, selecione Gerenciar>certificados & segredos. Em seguida, selecione Segredos do cliente>Novo segredo do cliente.

  8. Introduza uma descrição e expiração e, em seguida, selecione Adicionar.

  9. No campo Valor, copie o valor secreto do cliente. Depois que você se afastar desta página, ela não aparecerá novamente.

Agora você pode solicitar um token de acesso usando a ID do cliente e o segredo do cliente. Defina o parâmetro resource para o valor URI da ID da aplicação de destino. O token de acesso resultante pode ser apresentado ao aplicativo de destino por meio do cabeçalho de autorização OAuth 2.0 padrão. A autenticação do Serviço de Aplicativo valida e usa o token para indicar que o chamador está autenticado. Neste caso, o chamador é um aplicativo, não um usuário.

Essa abordagem 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, você deve executar a configuração extra.

  1. Defina uma função de aplicativo no manifesto do registro do aplicativo que representa o Serviço de Aplicativo ou o aplicativo Azure Functions que você deseja proteger.

  2. No registo da aplicação 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 da aplicação.

  4. Em Permissões de aplicativo, selecione a função de aplicativo que você criou anteriormente. Em seguida, selecione Adicionar permissões.

  5. Selecione Conceder consentimento de administrador para autorizar o aplicativo cliente a solicitar a permissão.

    Semelhante ao cenário anterior (antes de adicionar quaisquer funções), agora você pode solicitar um token de acesso para o mesmo recurso de destino. O token de acesso inclui uma roles declaração que contém as funções do aplicativo que foram autorizadas para o aplicativo cliente.

No código da aplicação no Serviço de Aplicações de destino ou em Azure Functions, agora pode validar se o token tem as funções esperadas. A autenticação do Serviço de Aplicativo não executa essa validação. Para mais informações, consulte Aceder a declarações de utilizador no código da aplicação.

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 que você usa para configurar a autenticação, as seguintes práticas recomendadas mantêm seu locatário e aplicativos mais seguros:

  • Configure cada aplicação no App Service com o seu próprio registo de aplicação no Microsoft Entra.
  • Atribua a cada aplicação do Serviço de Aplicações as suas próprias permissões e consentimento.
  • Evite o compartilhamento de permissões entre ambientes. Use registros de aplicativos separados para slots de implantação separados. Quando você está testando um novo código, essa prática pode ajudar a evitar que problemas afetem o aplicativo de produção.

Migrar para o Microsoft Graph

Algumas aplicações mais antigas podem ser configuradas com uma dependência do Azure AD Graph, que foi descontinuado e está agendado para uma desativação completa. Por exemplo, o código da sua aplicação pode chamar o Azure AD Graph para verificar a pertença a grupos como parte de um filtro de autorização num processo de middleware. Os aplicativos devem ser movidos para o Microsoft Graph. Para obter mais informações, consulte Migrar seus aplicativos do Azure AD Graph para o Microsoft Graph.

Durante essa migração, 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:

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

  • 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), essa configuração estará na additionalLoginParams matriz.
    • Se você estiver usando a API V2 (/authsettingsV2), essa configuração estará na loginParameters matriz.

    Você precisa remover qualquer referência a https://graph.windows.net, por exemplo. Essa alteração inclui o parâmetro resource, que o endpoint /v2.0 não suporta. Ele também inclui quaisquer escopos que você solicitar especificamente que sejam do Azure AD Graph.

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

Com essas alterações, quando a autenticação do Serviço de Aplicativo tenta entrar, ele não solicita mais permissões para o Azure AD Graph. Em vez disso, ele recebe um token para o Microsoft Graph. Qualquer uso desse token do código do seu aplicativo também precisa ser atualizado, conforme descrito em Migrar seus aplicativos do Azure AD Graph para o Microsoft Graph.

Conteúdo relacionado