Autenticação e autorização no Serviço de Aplicativo do Azure e no Azure Functions

O Serviço de Aplicativo do Azure fornece recursos internos de autenticação e autorização (chamados frequentemente de "Easy Auth") para que você possa conectar usuários e acessar dados sem precisar escrever nenhum código (ou o mínimo possível) no aplicativo Web, na API RESTful, no back-end para dispositivos móveis e no Azure Functions. Este artigo descreve como o Serviço de Aplicativo ajuda a simplificar a autenticação e autorização do aplicativo.

Por que usar a autenticação interna?

Não é necessário usar esse recurso para autenticação e autorização. Você pode usar os recursos de segurança em pacote na estrutura Web de sua escolha ou escrever seus próprios utilitários. No entanto, você precisa garantir que sua solução permaneça atualizada com as atualizações mais recentes de segurança, protocolo e navegador.

A implementação de uma solução segura para autenticação (conexão de usuários) e autorização (acesso a dados seguros) pode ser um processo muito complexo. Você precisa seguir as práticas recomendadas e os padrões do setor e manter sua implementação atualizada. O recurso interno de autenticação para o Serviço de Aplicativo e o Azure Functions pode facilitar e agilizar os processos ao fornecer autenticação pronta para uso com provedores de identidade federada, a fim de permitir que você se concentre no restante do aplicativo.

• O Serviço de Aplicativo do Azure permite integrar uma variedade de recursos de autenticação ao aplicativo Web ou à API sem implementá-los por conta própria.
• Ele é criado diretamente na plataforma e não requer nenhuma linguagem, SDK ou conhecimento de segurança; nem mesmo códigos para ser utilizado.
• Você pode integrar vários provedores de logon. Por exemplo, Microsoft Entra ID, Facebook, Google, Twitter.

Seu aplicativo pode precisar oferecer suporte a cenários mais complexos, como integração do Visual Studio ou consentimento incremental. Há várias soluções de autenticação diferentes disponíveis para dar suporte a esses cenários. Para saber mais, leia Cenários de identidade.

Provedores de identidade

O Serviço de Aplicativo usa identidade federada, na qual um provedor de identidade de terceiros gerencia as identidades do usuário e o fluxo de autenticação para você. Os provedores de identidade a seguir estão disponíveis por padrão:

Quando você configura esse recurso com um desses provedores, seu ponto de extremidade de entrada fica disponível para autenticação do usuário e para validação de tokens de autenticação do provedor. Você pode fornecer com facilidade aos usuários qualquer combinação dessas opções de conexão.

Considerações ao usar a autenticação interna

Habilitar esse recurso fará com que todas as solicitações para seu aplicativo sejam redirecionadas automaticamente para HTTPS, independentemente da configuração do Serviço de Aplicativo com relação à aplicação de HTTPS. Você pode desabilitar essa definição com a configuração requireHttps na configuração da V2. No entanto, recomenda-se manter HTTPS. Além disso, é preciso garantir que nenhum token de segurança seja transmitido por conexões HTTP não seguras.

O Serviço de Aplicativo pode ser usado para autenticação com ou sem restrição do acesso às APIs e ao conteúdo do site. Para restringir o acesso do aplicativo somente a usuários autenticados, defina Ação a ser tomada quando a solicitação não for autenticada para fazer logon com um dos provedores de identidade configurados. Para fazer a autenticação, mas não restringir o acesso, defina Ação a ser tomada quando a solicitação não for autenticada para "Permitir solicitações anônimas (nenhuma ação)".

Como ele funciona

Arquitetura de recursos

Fluxo de autenticação

Comportamento de autorização

Token Store

Registro em log e rastreamento

Arquitetura de recursos

O componente de middleware de autenticação e autorização é um recurso da plataforma que é executado na mesma VM que o seu aplicativo. Quando habilitado, toda solicitação HTTP de entrada passa por ele antes de ser manipulada pelo código do aplicativo.

O middleware de plataforma lida com várias coisas para seu aplicativo:

• Autentica usuários e clientes com o(s) provedore(s) de identidade especificado(s)
• Valida, armazena e atualiza tokens OAuth emitidos pelo(s) provedor(es) de identidade configurado(s)
• Gerencia a sessão autenticada
• Injeta informações de identidade em cabeçalhos da solicitação

O módulo é executado separadamente do código do aplicativo e pode ser configurado usando as configurações do Azure Resource Manager ou um arquivo de configuração. Não há necessidade de SDKs, linguagens de programação específicas ou alterações no código do aplicativo.

Arquitetura de recursos no Windows (implantação sem contêiner)

O módulo de autenticação e autorização executa como um módulo ISS nativo na mesma área restrita que o código do aplicativo. Quando habilitado, toda solicitação HTTP de entrada passa por ele antes de ser manipulada pelo código do aplicativo.

Arquitetura de recursos no Linux e em contêineres

O módulo de autenticação e autorização é executado em um contêiner separado, isolado do código do aplicativo. Ao usar o que é conhecido como o padrão embaixador, ele interage com o tráfego de entrada para executar uma funcionalidade semelhante à do Windows. Como ele não é executado no processo, nenhuma integração direta é possível com estruturas de linguagem específicas; no entanto, as informações relevantes que são necessárias ao seu aplicativo são transmitidas por meio de cabeçalhos de solicitação, conforme explicado abaixo.

Fluxo de autenticação

O fluxo de autenticação é o mesmo para todos os provedores, mas difere dependendo se você deseja entrar com o SDK do provedor:

• Sem SDK do provedor: o aplicativo delega o logon federado ao Serviço de Aplicativo. Esse é tipicamente o caso de aplicativos do navegador que podem apresentar a página de logon do provedor ao usuário. O código do servidor gerencia o processo de logon, portanto, ele também é chamado de fluxo direcionado ao servidor ou fluxo do servidor. Esse caso é aceitável para aplicativos de navegador e aplicativos móveis que usam um navegador inserido para autenticação.
• Com o provedor SDK: o aplicativo assina os usuários no provedor manualmente e, em seguida, envia o token de autenticação para o Serviço de Aplicativo para validação. Esse é tipicamente o caso de aplicativos sem navegador, que não podem apresentar a página de entrada do provedor ao usuário. O código do aplicativo gerencia o processo de entrada, portanto, ele também é chamado de fluxo direcionado ao cliente ou fluxo do cliente. Esse caso aplica-se a APIs REST, Azure Functions e clientes do navegador JavaScript, bem como aplicativos de navegador que precisam de mais flexibilidade no processo de entrada. Aplica-se também a aplicativos móveis nativos que conectam usuários usando o SDK do provedor.

Chamadas de um aplicativo de navegador confiável no Serviço de Aplicativo chamam outra API REST no Serviço de Aplicativo ou o Azure Functions pode ser autenticado usando o fluxo direcionado ao servidor. Para mais informações, consulte Personalizar entradas e saídas.

A tabela abaixo mostra as etapas do fluxo de autenticação.

Para navegadores do cliente, o Serviço de Aplicativo pode direcionar automaticamente todos os usuários não autenticados para /.auth/login/<provider>. Você também pode apresentar aos usuários um ou mais links /.auth/login/<provider> para entrar no aplicativo usando o provedor escolhido.

Comportamento de autorização

No portal do Azure, é possível configurar o Serviço de Aplicativo com vários comportamentos quando uma solicitação de entrada não é autenticada. Os cabeçalhos a seguir descrevem as opções.

Permitir solicitações não autenticadas

Esta opção adia a autorização de tráfego não autenticado para o código do aplicativo. Para solicitações autenticadas, o Serviço de Aplicativo também passa informações de autenticação nos cabeçalhos HTTP.

Essa opção oferece mais flexibilidade no processamento de solicitações anônimas. Por exemplo, permite que você apresente vários provedores de entrada aos usuários. No entanto, é necessário gravar o código.

Exigir autenticação

Esta opção rejeitará qualquer tráfego não autenticado para o aplicativo. Essa rejeição pode ser uma ação de redirecionamento para um dos provedores de identidade configurados. Nesses casos, um cliente de navegador é redirecionado para /.auth/login/<provider> para o provedor escolhido. Se a solicitação anônima originar-se de um aplicativo móvel nativo, a resposta retornada será HTTP 401 Unauthorized. Você também pode configurar a rejeição como HTTP 401 Unauthorized ou HTTP 403 Forbidden para todas as solicitações.

Com essa opção, você não precisa gravar nenhum código de autenticação no aplicativo. Uma autorização mais precisa, como autorização específica de função, pode ser tratada inspecionando as declarações do usuário (consulte Acessar declarações do usuário).

Token Store

O Serviço de Aplicativo fornece um armazenamento de token integrado, que é um repositório de tokens associados aos usuários dos aplicativos Web, APIs ou aplicativos móveis nativos. Ao habilitar a autenticação com qualquer provedor, esse armazenamento de token ficará imediatamente disponível para o aplicativo. Se o código do aplicativo precisar acessar dados desses provedores em nome do usuário, como:

• postar na linha do tempo do Facebook do usuário autenticado
• ler os dados corporativos do usuário com a API do Microsoft Graph

Normalmente, é necessário gravar código para coletar, armazenar e atualizar esses tokens no aplicativo. Com o Token Store, você apenas recupera os tokens quando precisar deles e informa ao Serviço de Aplicativo para atualizá-los quando tornarem-se inválidos.

Os tokens de ID, acesso e atualização são armazenados em cache para a sessão autenticada e são acessíveis apenas pelo usuário associado.

Se você não precisar trabalhar com tokens em seu aplicativo, poderá desabilitar o armazenamento de token na página Autenticação/autorização do seu aplicativo.

Registro em log e rastreamento

Se você habilitar o log de aplicativo, verá os rastreamentos de autenticação e autorização diretamente nos arquivos de log. Ao ver um erro de autenticação não esperado, é possível localizar com facilidade todos os detalhes examinando os logs do aplicativo existente. Se você habilitar rastreamento de solicitação com falha, será possível visualizar exatamente qual função o módulo de autenticação e autorização pode ter desempenhado em uma solicitação com falha. Nos logs de rastreamento, procure referências para um módulo nomeado EasyAuthModule_32/64.

Considerações ao usar o Azure Front Door

Ao usar Serviço de Aplicativo do Azure com Easy Auth atrás do Azure Front Door ou outros proxies reversos, algumas coisas adicionais precisam ser levadas em consideração.

1. Desabilitar o cache para o fluxo de trabalho de autenticação

   Consulte o Fluxo de trabalho Desabilitar o cache para autenticação para saber mais sobre como configurar regras no Azure Front Door para desabilitar o cache para páginas relacionadas à autenticação e à autorização.

2. Usar o ponto de extremidade do Front Door para redirecionamentos

   O Serviço de Aplicativo geralmente não fica acessível diretamente quando exposto por meio do Azure Front Door. Isso pode ser evitado, por exemplo, expondo o Serviço de Aplicativo por meio do Link Privado no Azure Front Door Premium. Para impedir que o fluxo de trabalho de autenticação redirecione o tráfego de volta para o Serviço de Aplicativo diretamente, é importante configurar o aplicativo para redirecionar para https://<front-door-endpoint>/.auth/login/<provider>/callback.

3. Verificar se o Serviço de Aplicativo está usando o URI de redirecionamento correto

   Em algumas configurações, o Serviço de Aplicativo está usando o FQDN do Serviço de Aplicativo como o URI de redirecionamento em vez do FQDN do Front Door. Isso causará um problema quando o cliente estiver sendo redirecionado para o Serviço de Aplicativo em vez do Front Door. Para alterar isso, a configuração forwardProxy precisa ser definida como Standard para fazer o Serviço de Aplicativo respeitar o cabeçalho X-Forwarded-Host definido pelo Azure Front Door.

   Outros proxies reversos, como Gateway de Aplicativo do Azure ou produtos de terceiros, podem usar cabeçalhos diferentes e precisam de uma configuração de forwardProxy diferente.

   Essa configuração não pode ser feita usando o portal do Azure e precisa ser feita usando az rest:

   Exportar configurações

   az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

   Configurações de atualização

   Procurar

   "httpSettings": {
     "forwardProxy": {
       "convention": "Standard"
     }
   }
   

   e verifique se convention está definido como Standard para respeitar o cabeçalho X-Forwarded-Host usado pelo Azure Front Door.

   Configurações de importação

   az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Mais recursos

• Como configurar seu aplicativo do Serviço de Aplicativo ou do Azure Functions para usar o logon do Microsoft Entra
• Personalizar entradas e saídas

• Trabalhar com tokens e sessões do OAuth
• Declarações de usuário e aplicativo
• Configuração baseada em arquivo

Exemplos:

• Tutorial: Adicionar a autenticação ao seu aplicativo Web em execução no Serviço de Aplicativo do Azure
• Tutorial: autenticar e autorizar usuários de ponta a ponta no Serviço de Aplicativo do Azure (Windows ou Linux)
• Integração do .NET Core com o EasyAuth do AppService do Azure (terceiros)
• Fazendo a autenticação do Serviço de Aplicativo do Azure funcionar com o .NET Core (terceiros)