Compartilhar via

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

  • Artigo

Observação

A partir de 1º de junho de 2024, todos os aplicativos recém-criados do Serviço de Aplicativo terão a opção de gerar um nome do host padrão exclusivo usando a convenção de nomenclatura <app-name>-<random-hash>.<region>.azurewebsites.net. Os nomes de aplicativos existentes permanecerão inalterados.

Exemplo: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Para obter mais detalhes, consulte Nome do Host Padrão Exclusivo para o Recurso Serviço de Aplicativo.

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, Facebook, Google, X.

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:

Provedor Ponto de extremidade de logon Diretrizes
Microsoft Entra /.auth/login/aad Logon da plataforma Microsoft Entra do Serviço de Aplicativo
Facebook /.auth/login/facebook Logon do Facebook no Serviço de Aplicativo
Google /.auth/login/google Logon do Google no Serviço de Aplicativo
X /.auth/login/x Login no Serviço de Aplicativo com o X
GitHub /.auth/login/github Serviço de Aplicativo Logon do GitHub
Entrar com a Apple /.auth/login/apple Serviço de Aplicativo Entrar com o logon da Apple (Versão Prévia)
Qualquer provedor do OpenID Connect /.auth/login/<providerName> Logon do OpenID Connect no Serviço de Aplicativo

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. As restrições de acesso podem ser definidas na seção de Autenticação>Configurações de autenticação do aplicativo Web. 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)".

Importante

Dê a cada registro de aplicativo a própria permissão e o próprio 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.

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.

Um diagrama de arquitetura que mostra solicitações sendo interceptadas por um processo na área restrita do site que interage com provedores de identidade antes de permitir o tráfego para o site implantado

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.

Etapa Sem SDK do provedor Com SDK do provedor
1. Conectar usuário Redireciona o cliente para /.auth/login/<provider>. O código do cliente coneta o usuário diretamente no SDK do provedor e recebe um token de autenticação. Para obter informações, consulte a documentação do provedor.
2. Pós-autenticação Provedor redireciona o cliente para /.auth/login/<provider>/callback. O código do cliente envia o token do provedor para /.auth/login/<provider> para a validação.
3. Estabelecer sessão autenticada O Serviço de Aplicativo adiciona um cookie autenticado à resposta. O Serviço de Aplicativo retorna o próprio token de autenticação para o código do cliente.
4. Fornecer conteúdo autenticado O cliente inclui o cookie de autenticação em solicitações subsequentes (manipuladas automaticamente pelo navegador). O código do cliente apresenta o token de autenticação no cabeçalho X-ZUMO-AUTH.

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

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 das verificações que você configurar aqui.

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.

Restringir acesso

  • Permitir solicitações não autenticadas: essa opção adia a autorização de tráfego não autenticado para o seu 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: essa opção rejeitará qualquer tráfego não autenticado para o seu aplicativo. A ação específica a ser executada é especificada na seção de Solicitações não autenticadas.

    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).

    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.

    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 HTTP 302 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> para o provedor escolhido.
  • HTTP 401 Não autorizado: recomendado para APIs Se a solicitação anônima vem de um aplicativo móvel nativo, a resposta retornada é um HTTP 401 Unauthorized. Também é possível configurar a rejeição como um HTTP 401 Unauthorized para todas as solicitações.
  • HTTP 403 Proibido Configura a rejeição como um HTTP 403 Forbidden para todas as solicitações.
  • HTTP 404 Não encontrado Configura a rejeição como um HTTP 404 Not found para todas as solicitações.

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

Exemplos: