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) como o provedor de autenticação.

Escolher um locatário para o aplicativo e os usuários

Antes que o aplicativo possa conectar usuários, primeiro você precisará registrá-lo em uma força de trabalho ou locatário externo. Caso esteja disponibilizando o aplicativo para funcionários ou convidados comerciais, registre o aplicativo em um locatário da força de trabalho. Se o aplicativo for para consumidores e clientes comerciais, registre-o em um locatário externo.

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

2. No menu à esquerda do aplicativo, selecione Autenticação e escolha Adicionar provedor de identidade.

3. Na página Adicionar um provedor de identidade, selecione Microsoft como o Provedor de identidade para conectar identidades da Microsoft e do Microsoft Entra.

4. Para o Tipo locatário, selecione a configuração da Força de Trabalho (locatário atual) para funcionários e convidados comerciais ou selecione Configuração externa para consumidores e clientes corporativos.

Escolha o registro do aplicativo

O recurso autenticação do Serviço de Aplicativo pode criar automaticamente um registro de aplicativo para você ou é possível usar um registro que você ou um administrador de diretório criou separadamente.

Crie um novo registro de aplicativo automaticamente, a menos que você precise criar um registro de aplicativo separadamente. Você poderá 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 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.

Configurar as verificações adicionais

Configure as verificações adicionais, que determina quais solicitações têm permissão para acessar o aplicativo. Você poderá personalizar 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 o Requisito de aplicativo cliente, escolha se deseja:

• Permitir solicitações somente deste próprio aplicativo
• Permitir solicitações de aplicativos cliente específicos
• Permitir solicitações de qualquer aplicativo (não recomendado)

Para o requisito de identidade, escolha se deseja:

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

Para requisitos de locatário, escolha se deseja:

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

Talvez seu aplicativo ainda precise tomar decisões de autorização adicionais no código. Para obter mais informações, consulte Usar uma política de autorização interna.

Definir configurações de autenticação

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.

Para restringir o acesso, decida se deseja:

• Exigir autenticação
• Permitir o acesso não autenticado

Para solicitações não autenticadas

• HTTP 302 Redirecionamento encontrado: recomendado para sites
• HTTP 401 Não autorizado: recomendado para APIs
• HTTP 403 Forbidden
• HTTP 404 Não encontrado

Selecione Repositório de tokens (recomendado). O repositório de tokens coleta, armazena e atualiza tokens para o aplicativo. Você poderá desabilitar isso mais tarde se o aplicativo não precisar de tokens ou se precisar otimizar o desempenho.

Adicionar o provedor de identidade

Caso selecionou a configuração da força de trabalho, poderá selecionar Avançar: Permissões e adicionar as 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. Caso 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 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.

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.

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

Ao realizar verificações de autorização no código do aplicativo, você poderá usar 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": []
            }
        }
    }
}

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, "aaaabbbb-0000-cccc-1111-dddd2222eeee") 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 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.

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 o registro do aplicativo não aparecer, verifique se você adicionou o escopo user_impersonation no registro do 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.
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 manterem seu locatário e seus aplicativos mais seguros:

• Configure cada aplicativo do Serviço de Aplicativo com seu próprio registro no Microsoft Entra.
• 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 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.

Próximas etapas

• Visão geral da Autenticação/Autorização do Serviço de Aplicativo.
• Tutorial: Autenticar e autorizar usuários de ponta a ponta no Serviço de Aplicativo do Azure

• Tutorial: autenticar e autorizar usuários em um aplicativo Web que acessa o Armazenamento do Azure e o Microsoft Graph
• Tutorial: Autenticar e autorizar usuários de ponta a ponta no Serviço de Aplicativo do Azure