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

O Serviço de Aplicativo do Azure fornece autenticação interna (entrada de usuários) e autorização (fornecendo acesso a dados seguros). Essas funcionalidades às vezes são chamadas de Autenticação Fácil. Você pode usá-los para conectar usuários e acessar dados escrevendo pouco ou nenhum código em seu aplicativo Web, API RESTful, servidor móvel e funções.

Este artigo descreve como o Serviço de Aplicativo ajuda a simplificar a autenticação e autorização do aplicativo.

Motivos para usar a autenticação interna

Para implementar a autenticação e a autorização, você pode usar os recursos de segurança agrupados em sua estrutura da Web de sua escolha ou escrever suas próprias ferramentas. A implementação de uma solução segura para autenticação e autorização pode ter um esforço significativo. Você precisa seguir as melhores práticas e padrões do setor. Você também precisa garantir que sua solução permaneça atualizada com as atualizações mais recentes de segurança, protocolo e navegador.

Os recursos internos do Serviço de Aplicativo e do Azure Functions podem economizar tempo e esforço fornecendo autenticação pronta para uso com provedores de identidade federados, para que você possa se concentrar no restante do aplicativo.

Com o Serviço de Aplicativo, você pode integrar recursos de autenticação ao aplicativo Web ou à API sem implementá-los por conta própria. Esse recurso é integrado diretamente à plataforma e não requer nenhum idioma específico, SDK, experiência em segurança ou código. Você pode integrar-se a vários provedores de credenciais, como Microsoft Entra, Facebook, Google e X.

Talvez seu aplicativo precise dar suporte a cenários mais complexos, como integração do Visual Studio ou consentimento incremental. Várias soluções de autenticação estão disponíveis para dar suporte a esses cenários. Para saber mais, confira as recomendações e cenários de autenticação.

Provedores de identidade

O Serviço de Aplicativo usa a identidade federada. Um provedor de identidade, seja da Microsoft ou não, gerencia as identidades de 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 a autenticação interna faz com que todas as solicitações para seu aplicativo sejam redirecionadas automaticamente para HTTPS, independentemente da configuração do Serviço de Aplicativo para impor HTTPS. Você pode desabilitar esse redirecionamento automático usando a configuração requireHttps nas configurações da V2. No entanto, recomendamos que você continue usando HTTPS e verifique se nenhum token de segurança é transmitido por conexões HTTP não seguras.

Você pode usar o Serviço de Aplicativo para autenticação com ou sem restringir o acesso ao conteúdo do site e às APIs. Defina restrições de acesso na seção Configurações>Autenticação>Configurações de Autenticação do seu aplicativo Web.

• Para restringir o acesso do aplicativo somente a usuários autenticados, defina a ação a ser executada quando a solicitação não for autenticada para entrar com um dos provedores de identidade configurados.
• Para autenticar, mas não restringir o acesso, defina a ação a ser executada quando a solicitação não for autenticada para Permitir solicitações anônimas (nenhuma ação).

Como ele funciona

Arquitetura de funcionalidades

O componente de middleware de autenticação e autorização é um recurso da plataforma que é executado na mesma máquina virtual que seu aplicativo. Quando você o habilita, cada solicitação HTTP de entrada passa por esse componente antes que seu aplicativo o manipule.

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

• Autentica usuários e clientes com os provedores de identidade especificados
• Valida, armazena e atualiza tokens OAuth que os provedores de identidade configurados emitiram
• Gerencia a sessão autenticada
• Injeta informações de identidade em cabeçalhos de solicitações HTTP

O módulo é executado separadamente do código do aplicativo. Você pode configurá-lo usando as configurações do Azure Resource Manager ou usando 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 funcionalidades no Windows (desenvolvimento sem uso de contêineres)

O módulo de autenticação e autorização é executado como um módulo IIS nativo no mesmo sandbox que o seu aplicativo. Quando você o habilita, cada solicitação HTTP de entrada passa por ela antes que seu aplicativo a manipule.

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. O módulo usa o padrão Ambassador para interagir com o tráfego de entrada para executar uma funcionalidade semelhante à do Windows. Como ele não é executado em processo, nenhuma integração direta com estruturas de linguagem específicas é possível. No entanto, as informações relevantes de que seu aplicativo precisa são passadas em cabeçalhos de solicitação.

Fluxo de autenticação

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

• Sem o SDK do provedor: o aplicativo delega a entrada federada ao Serviço de Aplicativo. Essa delegação é normalmente o caso de aplicativos de navegador, que podem apresentar a página de entrada do provedor ao usuário. O código do servidor gerencia o processo de entrada, portanto, ele também é chamado de fluxo direcionado pelo servidor ou fluxo de servidor.

  Esse caso é aceitável para aplicativos de navegador e aplicativos móveis que usam um navegador inserido para autenticação.

• Com o SDK do provedor: o aplicativo autentica os usuários no provedor manualmente. Em seguida, ele envia o token de autenticação para o Serviço de Aplicativo para validação. Esse processo normalmente é 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 pelo cliente ou fluxo de cliente.

  Esse caso se aplica a APIs REST, Azure Functions e clientes do navegador JavaScript, além de aplicativos de navegador que precisam de mais flexibilidade no processo de entrada. Ele também se aplica 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 para outra API REST no Serviço de Aplicativo ou no Azure Functions podem ser autenticadas por meio do fluxo direcionado pelo servidor. Para obter mais informações, confira Personalizar a entrada e a saída na autenticação no Serviço de Aplicativo do Azure.

A tabela a seguir 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 /.auth/login/<provider> links para entrar em seu aplicativo usando seu provedor de escolha.

Comportamento de autorização

No portal do Azure, você pode configurar o Serviço de Aplicativo com vários comportamentos quando uma solicitação de entrada não é autenticada. As seções a seguir descrevem as opções.

Acesso restrito

• Permitir solicitações não autenticadas: essa opção adia a autorização do 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, você deve escrever o código.

• Exigir autenticação: essa opção rejeita qualquer tráfego não autenticado para seu aplicativo. A ação específica a ser executada é especificada na seção solicitações não autenticadas posteriormente neste artigo.

  Com essa opção, você não precisa gravar nenhum código de autenticação no aplicativo. Você pode lidar com uma autorização mais detalhada, como autorização específica de função, analisando as reivindicações do usuário.

  Cuidado

  Esse tipo de restrição de acesso se aplica a todas as chamadas ao aplicativo, o que pode não ser útil para aplicativos que desejam uma página inicial publicamente disponível, como muitos aplicativos de página única. Se forem necessárias exceções, você precisará configurar caminhos excluídos em um arquivo de configuração.

  Observação

  Ao usar o provedor de identidade da Microsoft para os usuários na sua organização, o comportamento padrão é que qualquer usuário no seu locatário do Microsoft Entra pode solicitar um token para seu aplicativo. É possível configurar o aplicativo no Microsoft Entra para restringir o acesso ao seu aplicativo a um conjunto definido de usuários. O Serviço de Aplicativo também oferece algumas verificações básicas de autorização integradas que podem ajudar com algumas validações. Para saber mais sobre a autorização no Microsoft Entra, confira os Conceitos básicos de autorização do Microsoft Entra.

Solicitações não autenticadas

• Redirecionamento de HTTP 302 Encontrado: recomendado para sites: redireciona a ação para um dos provedores de identidade configurados. Nesses casos, um cliente do navegador é redirecionado para /.auth/login/<provider> para o provedor que você escolher.
• HTTP 401 Não autorizado: recomendado para APIs: retorna uma HTTP 401 Unauthorized resposta se a solicitação anônima vem de um aplicativo móvel nativo. Você também pode configurar a rejeição para que seja HTTP 401 Unauthorized em todas as solicitações.
• HTTP 403 Proibido: Configura a rejeição para ser HTTP 403 Forbidden para todas as solicitações.
• HTTP 404 Não encontrado: configura-se a rejeição como HTTP 404 Not found para todas as solicitações.

Token Store

O Serviço de Aplicativo fornece um repositório de tokens interno. Um repositório de tokens é um repositório de tokens associados aos usuários de seus 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, normalmente você deve escrever código para coletar, armazenar e atualizar esses tokens em seu aplicativo. As ações podem incluir:

• Poste na linha do tempo do Facebook do usuário autenticado.
• Leia os dados corporativos do usuário usando a API do Microsoft Graph.

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, tokens de acesso e tokens de atualização são armazenados em cache para a sessão autenticada. Somente o usuário associado pode acessá-los.

Se você não precisar trabalhar com tokens em seu aplicativo, poderá desabilitar o repositório de tokens na páginaAutenticação de > do aplicativo.

Log e rastreamento

Se você habilitar o registro em log do aplicativo, os rastreamentos de autenticação e autorização aparecerão diretamente em seus 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 o rastreamento de solicitação com falha, poderá ver exatamente qual função o módulo de autenticação e autorização pode desempenhar em uma solicitação com falha. Nos logs de rastreamento, procure referências para um módulo nomeado EasyAuthModule_32/64.

Mitigação de solicitação intersite forjada

A autenticação do Serviço de Aplicativo mitiga a solicitação intersite forjada inspecionando solicitações de cliente para as seguintes condições:

• É uma solicitação POST que foi autenticada por meio de um cookie de sessão.
• A solicitação veio de um navegador conhecido, conforme determinado pelo cabeçalho HTTP User-Agent .
• O cabeçalho HTTP Origin ou HTTP Referer está ausente ou não está na lista configurada de domínios externos aprovados para redirecionamento.
• O cabeçalho HTTP Origin está ausente ou não está na lista configurada de origens de CORS (compartilhamento de recursos entre origens).

Quando uma solicitação atende a todas essas condições, a autenticação do Serviço de Aplicativo a rejeita automaticamente. Você pode contornar essa lógica de mitigação adicionando seu domínio externo à lista de redirecionamento em Configurações>Autenticação>Editar configurações de autenticação>URLs de redirecionamento externo permitidos.

Metadados de recursos protegidos (versão prévia)

O Serviço de Aplicativo pode atender aos metadados de recursos protegidos do OAuth 2.0, conforme definido no RFC 9728. Isso pode ajudar os clientes do OAuth 2.0 a entender como interagir com seu aplicativo. Ele é necessário para autorização do servidor MCP (Model Context Protocol).

Durante o período de visualização, você pode habilitar um documento padrão de metadados de recurso protegido configurando a WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPES com uma lista de escopos necessária para o aplicativo, separada por vírgulas. Por exemplo, quando você permite que o Serviço de Aplicativo configure o provedor do Microsoft Entra para você, ele configurará um escopo como api://<client-id>/user_impersonation, substituindo <client-id> pela ID real do cliente do registro do aplicativo.

O documento de metadados de recurso protegido padrão inclui as seguintes propriedades:

Não há suporte para propriedades adicionais ao usar a configuração padrão.

Configurar o documento de metadados de recurso protegido padrão também altera a forma como o Serviço de Aplicativo lida com solicitações não autenticadas para APIs. Quando o aplicativo emite um desafio de autorização, ele inclui a URL dos metadados de recursos protegidos, que o cliente pode recuperar e processar. O desafio também inclui os escopos que você configurou na configuração do WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPES aplicativo.

Considerações sobre como usar o Azure Front Door

Quando você estiver usando o Serviço de Aplicativo do Azure com autenticação por trás do Azure Front Door ou outros proxies reversos, considere as ações a seguir.

Desabilitar o cache do Azure Front Door

Desabilite o cache do Azure Front Door para o fluxo de trabalho de autenticação.

Usar o ponto de extremidade do Azure Front Door para redirecionamentos

O Serviço de Aplicativo geralmente não é acessível diretamente quando é exposto pelo Azure Front Door. Você pode impedir esse comportamento, por exemplo, expondo o Serviço de Aplicativo usando o Link Privado do Azure no Azure Front Door Premium. Para impedir que o fluxo de trabalho de autenticação redirecione o tráfego de forma direta para o App Service. Para obter mais informações, consulte URI de redirecionamento.

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

Em algumas configurações, o Serviço de Aplicativo usa seu FQDN (nome de domínio totalmente qualificado) como o URI de redirecionamento, em vez do FQDN do Azure Front Door. Essa configuração causa um problema quando o cliente é redirecionado para o Serviço de Aplicativo em vez do Azure Front Door. Para alterá-lo, defina forwardProxy para Standard fazer com que o Serviço de Aplicativo respeite o X-Forwarded-Host cabeçalho definido pelo Azure Front Door.

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

Você não pode alterar a forwardProxy configuração usando o portal do Azure. Você precisa usar az rest.

Configurações de exportaçã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 get > auth.json

Atualizar configurações

Buscar por:

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

Certifique-se de que convention esteja definido como Standard para respeitar o cabeçalho usado pelo Azure Front Door.

Importar 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 put --body @auth.json

Conteúdo relacionado

Para obter mais informações sobre a autenticação do Serviço de Aplicativo, consulte:

• Configurar seu app de Serviço de Aplicativo ou Azure Functions para usar as credenciais do Microsoft Entra
• Personalizar a entrada e a saída na autenticação no Serviço de Aplicativo do Azure
• Trabalhar com tokens OAuth na autenticação do Serviço de Aplicativo do Azure
• Trabalhar com identidades de usuário na autenticação do Serviço de Aplicativo do Azure
• Configuração baseada em arquivo na autenticação do Serviço de Aplicativo do Azure

Para obter exemplos, consulte:

• Início Rápido: Adicionar autenticação de aplicativo ao 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
• Integração do .NET Core do Azure AppService Easy Auth (conteúdo não Microsoft GitHub)
• Obtendo a autenticação do Serviço de Aplicativo do Azure funcionando com o .NET Core (conteúdo não Microsoft GitHub)