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

2025-06-05

O Serviço de Aplicativo do Azure fornece recursos internos de autenticação (entrada de usuários) e autorização (fornecimento de acesso a dados seguros). Esses recursos são às vezes chamados de Easy Auth. Pode usá-los para autenticar utilizadores e aceder a dados escrevendo pouco ou nenhum código na sua aplicação web, API RESTful, servidor para dispositivos móveis e funções.

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

Razões para usar a autenticação interna

Para implementar autenticação e autorização, você pode usar os recursos de segurança incluídos em sua estrutura da Web de escolha, ou você pode escrever suas próprias ferramentas. A implementação de uma solução segura para autenticação e autorização pode exigir 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 federada, para que você possa se concentrar no restante do seu aplicativo.

Com o Serviço de Aplicativo, você pode integrar recursos de autenticação em seu aplicativo Web ou API sem implementá-los por conta própria. Esse recurso é integrado diretamente na plataforma e não requer nenhuma linguagem, SDK, experiência em segurança ou código em particular. Você pode integrá-lo com vários provedores de login, como Microsoft Entra, Facebook, Google e X.

Seu aplicativo pode precisar dar suporte a cenários mais complexos, como integração com o 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, consulte Cenários e recomendações de autenticação.

Fornecedores de identidade

O Serviço de Aplicativo usa identidade federada. Um provedor de identidade Microsoft ou não Microsoft gerencia as identidades de usuário e o fluxo de autenticação para você. Os seguintes provedores de identidade estão disponíveis por padrão:

Fornecedor	Endpoint de autenticação	Orientação passo-a-passo
Microsoft Entra	`/.auth/login/aad`	Serviço de Aplicativo Entrada na plataforma Microsoft Entra
Linkedin	`/.auth/login/facebook`	Início de sessão com Facebook no App Service
Google	`/.auth/login/google`	Início de sessão com o Google no Serviço de Aplicações
X	`/.auth/login/x`	Entrada no Serviço de Aplicativo X
GitHub	`/.auth/login/github`	Entrada no GitHub do Serviço de Aplicativo
Maçã	`/.auth/login/apple`	Início de sessão no App Service com início de sessão via Apple (pré-visualização)
Qualquer provedor OpenID Connect	`/.auth/login/<providerName>`	Início de sessão no Serviço de Aplicação OpenID Connect

Ao configurar esta funcionalidade com um destes provedores, o seu endpoint de autenticação está disponível para autenticação de utilizadores e validação de tokens de autenticação provenientes do provedor. Pode fornecer aos seus utilizadores qualquer número destas opções de início de sessão.

Considerações sobre o uso da autenticação interna

Habilitar a autenticação interna faz com que todas as solicitações ao seu aplicativo sejam redirecionadas automaticamente para HTTPS, independentemente da definição de configuração do Serviço de Aplicativo para impor HTTPS. Você pode desativar esse redirecionamento automático usando a requireHttps configuração na configuração V2. No entanto, recomendamos que você continue usando HTTPS e garanta que nenhum token de segurança seja 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> deautenticação>Configurações de autenticação do seu aplicativo Web:

Para restringir o acesso ao aplicativo apenas a usuários autenticados, defina 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ção a ser executada quando a solicitação não for autenticada como Permitir solicitações anônimas (nenhuma ação).

Importante

Você deve dar a cada registro de aplicativo sua própria permissão e consentimento. Evite a partilha de permissões entre ambientes através de registos de aplicações separados para blocos de implementaçã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.

Como funciona

Arquitetura de funcionalidades

O componente 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 da 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 emitidos pelos provedores de identidade configurados
Gerencia a sessão autenticada
Injeta informações de identidade em cabeçalhos de solicitação 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 são necessários SDKs, linguagens de programação específicas ou alterações no código do aplicativo.

Arquitetura de funcionalidades no Windows (implantação sem contentor)

O módulo de autenticação e autorização é executado como um módulo nativo do IIS na mesma área restrita do seu aplicativo. Quando você o habilita, todas as solicitações HTTP de entrada passam por ele antes que seu aplicativo o manipule.

Arquitetura de funcionalidades em Linux e contentores

O módulo de autenticação e autorização é executado em um contêiner separado que é 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 nos cabeçalhos de solicitação.

Fluxo de autenticação

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

Sem SDK do provedor: o aplicativo delega a entrada federada ao Serviço de Aplicativo. Esta delegação normalmente ocorre em aplicações de navegador, que podem apresentar a página de início de sessão do provedor ao utilizador. O código do servidor gerencia o processo de entrada, por isso também é chamado de fluxo direcionado ao servidor ou fluxo do servidor.

Este caso aplica-se a aplicações de browser e aplicações móveis que utilizam um browser incorporado para autenticação.
Com o SDK do provedor: a aplicação autentica os utilizadores no provedor manualmente. Em seguida, ele envia o token de autenticação ao Serviço de Aplicativo para validação. Esse processo geralmente é o caso de aplicativos sem navegador, que não podem apresentar a página de login do provedor ao usuário. O código do aplicativo gerencia o processo de entrada, por isso também é chamado de fluxo direcionado ao cliente ou fluxo do cliente.

Este caso aplica-se a APIs REST, Azure Functions e clientes de navegador JavaScript, além de aplicativos de navegador que precisam de mais flexibilidade no processo de entrada. Também se aplica a aplicações móveis nativas que permitem que os utilizadores iniciem sessão usando o SDK do fornecedor.

As 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 ao servidor. Para obter mais informações, consulte Personalizar início e término de sessão na autenticação do Serviço de Aplicativo do Azure.

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

Passo	Sem SDK do provedor	Com o SDK do fornecedor
1. Inicie sessão na conta do utilizador	O provedor redireciona o cliente para `/.auth/login/<provider>`.	O código do cliente autentica o utilizador diretamente através do SDK do fornecedor e recebe um token de autenticação. Para obter mais informações, consulte a documentação do provedor.
2. Realizar pós-autenticação	O provedor redireciona o cliente para `/.auth/login/<provider>/callback`.	O código do cliente envia o token do provedor para `/.auth/login/<provider>` verificação.
3. Estabeleça uma sessão autenticada	O Serviço de Aplicativo adiciona um cookie autenticado à resposta.	O Serviço de Aplicativo retorna seu próprio token de autenticação para o código do cliente.
4. Veicule conteúdo autenticado	O cliente inclui um cookie de autenticação em pedidos subsequentes (tratados automaticamente pelo navegador).	O código do cliente apresenta o token de autenticação no cabeçalho `X-ZUMO-AUTH`.

Para navegadores cliente, o Serviço de Aplicativo pode direcionar automaticamente todos os usuários não autenticados para o /.auth/login/<provider>. Você também pode apresentar aos usuários um ou mais /.auth/login/<provider> links para entrar em seu aplicativo usando o provedor de sua 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.

Importante

Por padrão, esse recurso fornece apenas autenticação, não autorização. Seu aplicativo ainda pode precisar tomar decisões de autorização, além de quaisquer verificações que você configurar aqui.

Acesso restrito

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.

Esta opção proporciona mais flexibilidade no tratamento de pedidos anónimos. Por exemplo, permite-lhe apresentar vários provedores de autenticação aos seus utilizadores. No entanto, você deve escrever código.
Exigir autenticação: esta opção rejeita qualquer tráfego não autenticado para o seu aplicativo. A ação específica a ser tomada é especificada na seção Solicitações não autenticadas mais adiante neste artigo.

Com essa opção, você não precisa escrever nenhum código de autenticação em seu aplicativo. Você pode lidar com uma autorização mais fina, como autorização específica da função, inspecionando as declarações do usuário.

Atenção

Restringir o acesso dessa forma se aplica a todas as chamadas para seu aplicativo, o que pode não ser desejável para aplicativos que desejam uma home page disponível publicamente, como em muitos aplicativos de página única. Se forem necessárias exceções, você precisará configurar caminhos excluídos em um arquivo de configuração.

Nota

Ao usar o provedor de identidade da Microsoft para utilizadores na sua organização, o comportamento padrão é que qualquer utilizador no seu locatário do Microsoft Entra pode solicitar um token para a sua aplicação. Você pode configurar o aplicativo no Microsoft Entra se quiser restringir o acesso ao seu aplicativo a um conjunto definido de usuários. O Serviço de Aplicação também oferece algumas verificações de autorização internas básicas que podem ajudar com algumas validações. Para saber mais sobre autorização no Microsoft Entra, consulte Noções básicas de autorização do Microsoft Entra.

Quando você estiver usando o provedor de identidade da Microsoft para usuários em sua organização, o comportamento padrão é que qualquer usuário em seu locatário do Microsoft Entra pode solicitar um token para seu aplicativo. Você pode configurar o aplicativo no Microsoft Entra se quiser restringir o acesso ao seu aplicativo a um conjunto definido de usuários. O Serviço de Aplicativo também oferece algumas verificações de autorização internas básicas que podem ajudar com algumas validações. Para saber mais sobre autorização no Microsoft Entra, consulte Noções básicas de autorização do Microsoft Entra.

Pedidos não autenticados

HTTP 302 Redirecionamento Encontrado: recomendado para sites: Redireciona a ação para um dos provedores de identidade configurados. Nesses casos, um cliente de navegador é redirecionado para /.auth/login/<provider> 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 vier de um aplicativo móvel nativo. Você também pode configurar a rejeição para que seja HTTP 401 Unauthorized para todas as solicitações.
HTTP 403 Proibido: Configura a rejeição para ser aplicada a todas HTTP 403 Forbidden as solicitações.
HTTP 404 Não encontrado: Configura a rejeição para ser HTTP 404 Not found em todas as solicitações.

Loja de tokens

O Serviço de Aplicativo fornece um armazenamento 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. Quando você habilita a autenticação com qualquer provedor, esse armazenamento de tokens fica imediatamente disponível para seu aplicativo.

Se o código do seu aplicativo precisar acessar dados desses provedores em nome do usuário, você normalmente deve escrever código para coletar, armazenar e atualizar esses tokens em seu aplicativo. As ações podem incluir:

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

Com a loja de tokens, você apenas recupera os tokens quando precisar deles e diz ao Serviço de Aplicativo para atualizá-los quando eles se tornarem inválidos.

Os tokens de ID, os tokens de acesso e os tokens de atualização são armazenados em cache para a sessão autenticada. Somente o usuário associado pode acessá-los.

Se não precisar de trabalhar com tokens na sua aplicação, pode desativar a loja de tokens na páginaAutenticação de > da sua aplicação.

Registo e rastreio

Se você habilitar o log de aplicativos, os rastreamentos de autenticação e autorização aparecerão diretamente em seus arquivos de log. Se vir um erro de autenticação que não esperava, pode encontrar convenientemente todos os detalhes consultando os registos de aplicações existentes.

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 a um módulo chamado EasyAuthModule_32/64.

Mitigação da falsificação de pedidos entre sites

A autenticação do Serviço de Aplicativo atenua a falsificação de solicitações entre sites inspecionando as solicitações do cliente quanto às seguintes condições:

É um POST pedido autenticado através 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 compartilhamento de recursos entre origens (CORS).

Quando uma solicitação preenche 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 o seu domínio externo à lista de redirecionamento em Configurações>Autenticação>Editar configurações de autenticação>URLs de redirecionamento externo permitidas.

Considerações para 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 seguintes ações.

Desabilitar o cache do Azure Front Door

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

Usar o endpoint do Azure Front Door para redirecionamentos

O App Service geralmente não é acessível diretamente quando é exposto pelo Azure Front Door. Você pode evitar esse comportamento, por exemplo, expondo o Serviço de Aplicativo usando o Azure Private Link 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. Para obter mais informações, consulte Redirecionar URI.

Verifique 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 da Porta da Frente do Azure. Essa configuração causa um problema quando o cliente é redirecionado para o Serviço de Aplicativo em vez da Porta Frontal do Azure. Para alterá-lo, defina forwardProxy como Standard para 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 Azure Application Gateway ou produtos que não sejam da Microsoft, podem usar cabeçalhos diferentes e precisar de uma configuração diferente forwardProxy .

Não é possível 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

Pesquisar por:

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

Certifique-se de que convention está configurado para Standard de modo a respeitar o cabeçalho X-Forwarded-Host que o Azure Front Door usa.

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

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

Para amostras, consulte:

Guia de início rápido: adicionar autenticação de aplicativo 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
Integração do .NET Core do Azure AppService Easy Auth (conteúdo não Microsoft GitHub)
Como fazer com que a autenticação do Serviço de Aplicativo do Azure funcione com o .NET Core (conteúdo do GitHub que não seja da Microsoft)