Partilhar via

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

  • Artigo

Nota

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

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

Para obter mais detalhes, consulte Nome de host padrão exclusivo para recurso do Serviço de Aplicativo.

O Serviço de Aplicativo do Azure fornece recursos internos de autenticação e autorização (às vezes chamados de "Autenticação Fácil"), para que você possa entrar em usuários e acessar dados escrevendo código mínimo ou nenhum em seu aplicativo Web, API RESTful e back-end móvel, além do Azure Functions. Este artigo descreve como o Serviço de Aplicativo ajuda a simplificar a autenticação e a autorização para seu aplicativo.

Por que usar a autenticação integrada?

Não é necessário usar esse recurso para 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 seus próprios utilitários. No entanto, você precisará 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 (entrada de usuários) e autorização (fornecimento de acesso a dados seguros) pode exigir um esforço significativo. Você deve se certificar de seguir as melhores práticas e padrões do setor e manter sua implementação atualizada. O recurso de autenticação interno para o Serviço de Aplicativo e o Azure Functions pode economizar tempo e esforço fornecendo autenticação pronta para uso com provedores de identidade federada, permitindo que você se concentre no restante do seu aplicativo.

  • O Serviço de Aplicativo do Azure permite que você integre uma variedade de recursos de autenticação em seu aplicativo Web ou API sem implementá-los por conta própria.
  • Ele é construído diretamente na plataforma e não requer nenhuma linguagem específica, SDK, experiência em segurança ou mesmo qualquer código para utilizar.
  • Você pode integrar com vários provedores de login. Por exemplo, Microsoft Entra, Facebook, Google, X.

Seu aplicativo pode precisar dar suporte a cenários mais complexos, como integração com 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.

Fornecedores de identidade

O Serviço de Aplicativo usa identidade federada, na qual um provedor de identidade de terceiros 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:

Provider Ponto de extremidade de entrada Orientação de instruções
Microsoft Entra /.auth/login/aad Login na plataforma Microsoft Entra do Serviço de Aplicativo
Facebook /.auth/login/facebook Login do Facebook do Serviço de Aplicativo
Google /.auth/login/google Login do Google do Serviço de Aplicativo
X /.auth/login/x Login do Serviço de Aplicativo X
GitHub /.auth/login/github Login no GitHub do Serviço de Aplicativo
Iniciar sessão com a Apple /.auth/login/apple Iniciar sessão no Serviço de Aplicação com início de sessão Apple (Pré-visualização)
Qualquer provedor OpenID Connect /.auth/login/<providerName> Login do Serviço de Aplicativo OpenID Connect

Quando você configura esse recurso com um desses provedores, seu ponto de extremidade de entrada está disponível para autenticação do usuário e para validação de tokens de autenticação 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 esse recurso fará 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 isso com a requireHttps configuração na configuração V2. No entanto, recomendamos manter o HTTPS, e você deve 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 restringir o acesso ao conteúdo do site e às APIs. As restrições de acesso podem ser definidas na seçã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 fazer login 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. Ao testar um novo código, essa prática pode ajudar a evitar que problemas afetem o aplicativo de produção.

Como funciona

Arquitetura de recursos

Fluxo de autenticação

Comportamento de autorização

Arquivo de tokens

Registo e rastreio

Arquitetura de recursos

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

Um diagrama de arquitetura mostrando solicitações sendo intercetadas 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 da plataforma lida com várias coisas para seu aplicativo:

  • Autentica usuários e clientes com o(s) provedor(es) 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 de solicitação HTTP

O módulo é executado separadamente do código do aplicativo e pode ser configurado 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 recursos no Windows (implantação sem contêiner)

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 habilitado, cada solicitação HTTP de entrada passa por ele antes de ser manipulada pelo seu aplicativo.

Arquitetura de recursos em Linux e contêineres

O módulo de autenticação e autorização é executado em um contêiner separado, isolado do código do aplicativo. Usando o que é conhecido como o padrão Ambassador, ele interage com o tráfego de entrada para executar uma funcionalidade semelhante à do Windows. Como 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 usando 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 a entrada federada ao Serviço de Aplicativo. Este é normalmente o caso dos aplicativos do navegador, que podem apresentar a página de login do provedor para o usuário. 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: o aplicativo conecta os usuários ao provedor manualmente e, em seguida, envia o token de autenticação ao Serviço de Aplicativo para validação. Normalmente, esse é 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 browser JavaScript, bem como a aplicações de browser que necessitam de mais flexibilidade no processo de início de sessão. Também se aplica a aplicativos móveis nativos que fazem login de usuários usando o SDK do provedor.

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 usando o fluxo direcionado ao servidor. Para obter mais informações, consulte Personalizar entradas e saídas.

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

Passo Sem SDK do provedor Com SDK do provedor
1. Iniciar sessão do utilizador Redireciona o cliente para /.auth/login/<provider>. O código do cliente conecta o usuário diretamente com o 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 O provedor redireciona o cliente para /.auth/login/<provider>/callback. O código do cliente publica o token do provedor para validação /.auth/login/<provider> .
3. Estabeleça uma sessão autenticada O Serviço de Aplicativo adiciona 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 cookie de autenticação em solicitações subsequentes (tratadas automaticamente pelo navegador). O código do cliente apresenta o token de autenticação no X-ZUMO-AUTH cabeçalho.

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

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.

No portal do Azure, você pode configurar o Serviço de Aplicativo com vários comportamentos quando a solicitação de entrada não é autenticada. Os títulos seguintes descrevem as opções.

Restringir o acesso

  • 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 fornecedores de início de sessão aos seus utilizadores. No entanto, você deve escrever código.

  • Exigir autenticação Esta opção rejeitará 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.

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

    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.

    Nota

    Ao usar o provedor de identidade da Microsoft para utilizadores a sua organização, o comportamento padrão é que qualquer utilizador no seu inquilino 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.

Pedidos não autenticados

  • HTTP 302 Encontrado redirecionamento: recomendado para sites Redireciona a ação para um dos provedores de identidade configurados. Nesses casos, um cliente de navegador é redirecionado para o provedor escolhido /.auth/login/<provider> .
  • HTTP 401 Não autorizado: recomendado para APIs Se a solicitação anônima vier de um aplicativo móvel nativo, a resposta retornada será um HTTP 401 Unauthorizedarquivo . Você também pode configurar a rejeição para ser 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.

Arquivo de tokens

O Serviço de Aplicativo fornece um repositório de tokens interno, que é 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, como:

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

Normalmente, você deve escrever código para coletar, armazenar e atualizar esses tokens em seu aplicativo. 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 e são acessíveis apenas pelo usuário associado.

Se não precisar de trabalhar com tokens na sua aplicação, pode desativar a loja de tokens na página Autenticação/Autorização da sua aplicação.

Registo e rastreio

Se você habilitar o log de aplicativos, verá rastreamentos de autenticação e autorizaçã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 ter desempenhado em uma solicitação com falha. Nos logs de rastreamento, procure referências a um módulo chamado EasyAuthModule_32/64.

Mitigação de falsificação de solicitação entre sites

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

  • É uma solicitação POST autenticada usando 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 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 atenuação adicionando seu domínio externo à lista de redirecionamento para Autenticação>Editar configurações de>autenticação URLs de redirecionamento externo permitidas.

Considerações ao usar o Azure Front Door

Ao usar o Serviço de Aplicativo do Azure com autenticação por trás do Azure Front Door ou outros proxies reversos, algumas coisas adicionais devem ser levadas em consideração.

  • Desative o cache para o fluxo de trabalho de autenticação.

    Consulte Desabilitar cache para fluxo de trabalho de 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.

  • Use o ponto de extremidade Front Door para redirecionamentos.

    O Serviço de Aplicativo geralmente não é acessível diretamente quando exposto por meio da Porta da Frente do Azure. Isso pode ser evitado, por exemplo, expondo o Serviço de Aplicativo via Link Privado no Azure Front Door Premium. Para evitar 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 de volta para https://<front-door-endpoint>/.auth/login/<provider>/callback.

  • Verifique 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 da Porta Frontal. Isso levará a um problema quando o cliente estiver sendo redirecionado para o Serviço de Aplicativo em vez do Front Door. Para alterar isso, a forwardProxy configuração precisa ser definida 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 Azure Application Gateway ou produtos de terceiros podem usar cabeçalhos diferentes e precisar de uma configuração forwardProxy diferente.

    Essa configuração não pode ser feita por meio do portal do Azure hoje e precisa ser feita via 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

    Procurar

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

    e certifique-se de que convention está definido para Standard respeitar o X-Forwarded-Host 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

Mais recursos

Exemplos: