Compartilhar via

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

  • Artigo

Este artigo mostra como personalizar a entrada e a saída do usuário usando a autenticação e a autorização no Serviço de Aplicativo.

Usar vários provedores de entrada

A configuração do portal não oferece uma maneira prática de apresentar diversos provedores de entrada aos usuários (como o Facebook e o X). No entanto, não é difícil adicionar a funcionalidade ao aplicativo. As etapas são destacadas como a seguir:

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

Em Ação a tomar quando a solicitação não está autenticada, selecione Permitir solicitações anônimas (nenhuma ação).

Na página de entrada, na barra de navegação, ou em qualquer outro local do aplicativo, adicione um link de entrada a cada um dos provedores que você habilitou (/.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 respectiva página de entrada é aberta para que ele entre.

Para redirecionar o usuário pós-entada para uma URL personalizada, use o parâmetro de cadeia de caracteres de consulta post_login_redirect_uri (não deve ser confundido com o URI de redirecionamento na configuração do provedor de identidade). Por exemplo, para orientar o usuário para /Home/Index após entrar, use o seguinte código HTML:

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

Entrada direcionada ao cliente

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

Para validar o token do provedor, o aplicativo Serviço de Aplicativo deve ser configurado primeiro com o provedor desejado. Em runtime, depois de recuperar o token de autenticação do seu provedor, poste o token em /.auth/login/<provider> para 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. Para obter detalhes, consulte a tabela a seguir:

Valor do provedor Necessário no corpo da solicitação Comentários
aad {"access_token":"<access_token>"} As propriedades id_token, refresh_token e expires_in são opcionais.
microsoftaccount {"access_token":"<access_token>"} ou {"authentication_token": "<token>" Prefere-se authentication_token em vez de access_token. A propriedade expires_in é opcional.
Ao solicitar o token de serviços em tempo real, sempre solicitar o wl.basic escopo.
google {"id_token":"<id_token>"} A propriedade authorization_code é opcional. Fornecer um valor em authorization_code adicionará um token de acesso e um token de atualização ao armazenamento de tokens. Quando especificado, authorization_code também pode ser acompanhado por uma propriedade redirect_uri.
facebook {"access_token":"<user_access_token>"} Use um válido token de acesso do usuário do Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

Observação

O provedor do GitHub para autenticação do Serviço de Aplicativo não dá suporte à entrada e saída personalizadas.

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

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

Uma vez que esse token de sessão, você pode acessar os recursos de aplicativo protegido, adicionando o X-ZUMO-AUTH cabeçalho às 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 ao ponto de extremidade /.auth/logout do aplicativo. A solicitação GET faz o seguinte:

  • Limpa os cookies de autenticação da sessão atual.
  • Exclui os tokens do usuário atual do Token Store.
  • Para o Microsoft Entra e o Google, executa um logout no lado do servidor no provedor de identidade.

Aqui está um link de saída simples em uma página da Web:

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

Por padrão, uma saída com êxito redireciona o cliente para a URL /.auth/logout/complete. É possível alterar a página de redirecionamento pós-saída, adicionando o parâmetro de consulta post_logout_redirect_uri. 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 permitido para o 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 aplicativo, 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 ao servidor, consequentemente não são preservados por padrão depois que a assinatura OAuth é concluída e redirecionada de volta ao aplicativo. Portanto, os usuários obtêm uma experiência abaixo do ideal quando precisam navegar novamente para a âncora desejada. Essa limitação aplica-se a todas as soluções de autenticação do lado do servidor.

Na autenticação do Serviço de Aplicativo, é possível preservar os fragmentos de URL na assinatura OAuth. Para fazer isso, defina uma configuração de aplicativo chamada WEBSITE_AUTH_PRESERVE_URL_FRAGMENT para true. Você pode fazer isso no portal do Azure ou simplesmente executar o comando a seguir no Azure Cloud Shell:

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

Definir a dica de domínio de contas de entrada

Tanto a Conta Microsoft quanto o Microsoft Entra ID permitem entrar a partir de vários domínios. Por exemplo, a Conta da Microsoft permite contas de outlook.com, live.com e hotmail.com. O Microsoft Entra ID 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 marca (como contoso.com). Para sugerir o nome de domínio das contas de entrada, siga estas etapas.

  1. Em https://resources.azure.com, na parte superior da página, selecione Ler/Gravar.

  2. No navegador à esquerda, navegue até assinaturas><subscription_name>resourceGroups><resource_group_name>>provedores>Microsoft.Web>sites><app_name>>config>authsettingsV2.

  3. Clique em Editar.

  4. Adicione uma matriz loginParameters com um item domain_hint.

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

  5. Clique em Put.

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

Importante

É possível que o cliente remova o parâmetro domain_hint depois de receber a URL de redirecionamento e, em seguida, faça logon com um domínio diferente. Portanto, embora essa função seja conveniente, ela não é um recurso de segurança.

Autorizar ou negar usuários

Embora o Serviço de Aplicativo se encarrega 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 determinados 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 o provedor de identidade pode ser capaz de ajudar sem a necessidade de alterações de código.

Nível do servidor (somente aplicativos do Windows)

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

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

  2. No gerenciador de 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 código de configuração a seguir e clique em Salvar. Se Web.config já existir, basta adicionar o elemento <authorization> a tudo nele. Adicione as contas que você deseja permitir no elemento <allow>.

    <?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 de provedor de identidade

O provedor de identidade pode fornecer determinada autorização de distribuição. Por exemplo:

Nível de aplicativo

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 tiver suporte, você deverá escrever um código personalizado para autorizar usuários com base nas declarações do usuário.

Mais recursos