Personalizar entrada e saída na autenticação do Serviço de Aplicativo do Azure

Este artigo mostra como personalizar entradas e saídas de usuários ao usar a autenticação e autorização internas no Serviço de Aplicativo.

Utilizar vários fornecedores de início de sessão

A configuração do portal não oferece uma maneira completa de apresentar vários provedores de login para seus usuários (como Facebook e X). No entanto, não é difícil adicionar a funcionalidade ao seu aplicativo. Os passos são detalhados abaixo:

Primeiro, na página Autenticação/Autorização no portal do Azure, configure cada um dos provedores de identidade que você deseja habilitar.

Em Ação a ser executada quando a solicitação não for autenticada, selecione Permitir solicitações anônimas (nenhuma ação).

Na página de início de sessão, na barra de navegação ou em qualquer outra localização da sua aplicação, adicione uma ligação de início de sessão a cada um dos fornecedores que ativou (/.auth/login/<provider>). Por exemplo:

<a href="/.auth/login/aad">Log in with Microsoft Entra</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/x">Log in with X</a>
<a href="/.auth/login/apple">Log in with Apple</a>

Quando o usuário clica em um dos links, a respetiva página de login é aberta para entrar no usuário.

Para redirecionar o usuário pós-login para uma URL personalizada, use o post_login_redirect_uri parâmetro query string (não confundir com o URI de redirecionamento na configuração do provedor de identidade). Por exemplo, para navegar o usuário para /Home/Index depois de entrar, use o seguinte código HTML:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Início de sessão dirigido ao cliente

Em uma entrada direcionada ao cliente, o aplicativo entra o usuário no provedor de identidade usando um SDK específico do provedor. Em seguida, o código do aplicativo envia o token de autenticação resultante ao Serviço de Aplicativo para validação (consulte Fluxo de autenticação) usando uma solicitação HTTP POST. Essa validação em si não concede acesso aos recursos desejados do aplicativo, mas uma validação bem-sucedida lhe dará um token de sessão que você pode usar para acessar os recursos do aplicativo.

Para validar o token do provedor, o aplicativo do Serviço de Aplicativo deve primeiro ser configurado com o provedor desejado. No tempo de execução, depois de recuperar o token de autenticação do seu provedor, poste o token para /.auth/login/<provider> validação. Por exemplo:

POST https://<appname>.azurewebsites.net/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

O formato do token varia ligeiramente de acordo com o provedor. Consulte a tabela a seguir para obter detalhes:

Se o token do provedor for validado com êxito, a API retornará com um authenticationToken no corpo da resposta, que é o seu token de sessão. Para obter mais informações sobre as declarações de usuário, consulte Trabalhar com identidades de usuário na autenticação do Serviço de Aplicativo do Azure.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Depois de ter esse token de sessão, você pode acessar recursos protegidos do aplicativo adicionando o X-ZUMO-AUTH cabeçalho às suas solicitações HTTP. Por exemplo:

GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Sair de uma sessão

Os usuários podem iniciar uma saída enviando uma GET solicitação para o ponto de /.auth/logout extremidade do aplicativo. A GET solicitação faz o seguinte:

• Limpa os cookies de autenticação da sessão atual.
• Exclui os tokens do usuário atual do repositório de tokens.
• Para Microsoft Entra e Google, executa uma saída do lado do servidor no provedor de identidade.

Esta é uma ligação simples de fim de sessão numa página Web:

<a href="/.auth/logout">Sign out</a>

Por padrão, uma saída bem-sucedida redireciona o cliente para a URL /.auth/logout/complete. Você pode alterar a página de redirecionamento pós-saída adicionando o post_logout_redirect_uri parâmetro query. Por exemplo:

GET /.auth/logout?post_logout_redirect_uri=/index.html

É recomendável codificar o valor de post_logout_redirect_uri.

Ao usar URLs totalmente qualificadas, a URL deve ser hospedada no mesmo domínio ou configurada como uma URL de redirecionamento externo permitida para seu aplicativo. No exemplo a seguir, para redirecionar para https://myexternalurl.com que não está hospedado no mesmo domínio:

GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com

Execute o seguinte comando no Azure Cloud Shell:

az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls "https://myexternalurl.com"

Preservar fragmentos de URL

Depois que os usuários entram no seu aplicativo, eles geralmente querem ser redirecionados para a mesma seção da mesma página, como /wiki/Main_Page#SectionZ. No entanto, como os fragmentos de URL (por exemplo, #SectionZ) nunca são enviados para o servidor, eles não são preservados por padrão depois que o logon OAuth é concluído e redireciona de volta para seu aplicativo. Os usuários obtêm uma experiência abaixo do ideal quando precisam navegar para a âncora desejada novamente. Esta limitação aplica-se a todas as soluções de autenticação do lado do servidor.

Na autenticação do Serviço de Aplicativo, você pode preservar fragmentos de URL na entrada OAuth. Para fazer isso, defina uma configuração de aplicativo chamada WEBSITE_AUTH_PRESERVE_URL_FRAGMENT como true. Você pode fazer isso no portal do Azure ou simplesmente executar o seguinte comando no Azure Cloud Shell:

az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"

Definindo a dica de domínio de contas de entrada

Tanto a Conta Microsoft como o Microsoft Entra permitem-lhe iniciar sessão a partir de vários domínios. Por exemplo, a Conta da Microsoft permite contas outlook.com, live.com e hotmail.com . O Microsoft Entra permite qualquer número de domínios personalizados para as contas de entrada. No entanto, talvez você queira acelerar seus usuários diretamente para sua própria página de entrada do Microsoft Entra com sua própria marca (como contoso.com). Para sugerir o nome de domínio das contas de início de sessão, siga estes passos.

1. Em https://resources.azure.com, Na parte superior da página, selecione Leitura/Gravação.

2. No navegador à esquerda, navegue até subscriptions<>subscription-name>resourceGroups<>resource-group-name>>providers>Microsoft.Web>sites<>app-name>>config>authsettingsV2.

3. Clique em Editar.

4. Adicione uma loginParameters matriz com um domain_hint item.

   "identityProviders": {
       "azureActiveDirectory": {
           "login": {
               "loginParameters": ["domain_hint=<domain-name>"],
           }
       }
   }
   

5. Clique em Colocar.

Essa configuração acrescenta o domain_hint parâmetro de cadeia de caracteres de consulta à URL de redirecionamento de login.

Autorizar ou negar usuários

Embora o Serviço de Aplicativo cuide do caso de autorização mais simples (ou seja, rejeitar solicitações não autenticadas), seu aplicativo pode exigir um comportamento de autorização mais refinado, como limitar o acesso a apenas um grupo específico de usuários. Em certos casos, você precisa escrever código de aplicativo personalizado para permitir ou negar acesso ao usuário conectado. Em outros casos, o Serviço de Aplicativo ou seu provedor de identidade pode ajudar sem exigir alterações de código.

• Nível do servidor
• Nível do provedor de identidade
• Nível de aplicação

Nível do servidor (somente aplicativos do Windows)

Para qualquer aplicativo do Windows, você pode definir o comportamento de autorização do servidor Web IIS, editando o arquivo Web.config . Os aplicativos Linux não usam o IIS e não podem ser configurados por meio do Web.config.

1. Navegue para https://<app-name>.scm.azurewebsites.net/DebugConsole

2. No explorador do navegador dos arquivos do Serviço de Aplicativo, navegue até site/wwwroot. Se um Web.config não existir, crie-o selecionando+> Novo arquivo.

3. Selecione o lápis para Web.config para editá-lo. Adicione o seguinte código de configuração e clique em Salvar. Se Web.config já existe, basta adicionar o <authorization> elemento com tudo nele. Adicione as contas que você deseja permitir no <allow> elemento .

   <?xml version="1.0" encoding="utf-8"?>
   <configuration>
      <system.web>
         <authorization>
           <allow users="user1@contoso.com,user2@contoso.com"/>
           <deny users="*"/>
         </authorization>
      </system.web>
   </configuration>
   

Nível do provedor de identidade

O provedor de identidade pode fornecer determinada autorização turn-key. Por exemplo:

• Você pode gerenciar o acesso de nível empresarial diretamente no Microsoft Entra. Para obter instruções, consulte Como remover o acesso de um usuário a um aplicativo.
• Para o Google, os projetos da API do Google que pertencem a uma organização podem ser configurados para permitir o acesso apenas a usuários em sua organização (consulte a página de suporte Configuração do OAuth 2.0 do Google).

Nível de aplicação

Se qualquer um dos outros níveis não fornecer a autorização de que você precisa, ou se sua plataforma ou provedor de identidade não for suportado, você deverá escrever código personalizado para autorizar usuários com base nas declarações do usuário.

Mais recursos

• Tutorial: Autenticar e autorizar utilizadores ponto a ponto
• Variáveis de ambiente e configurações de aplicativo para autenticação