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

  • Artigo

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 Twitter). 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 the Microsoft Identity Platform</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/twitter">Log in with Twitter</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:

Valor do provedor Obrigatório no corpo do pedido Comentários
aad {"access_token":"<access_token>"} As id_tokenpropriedades , refresh_token, e são expires_in opcionais.
microsoftaccount {"access_token":"<access_token>"} ou {"authentication_token": "<token>" authentication_token é preferível a access_token. A expires_in propriedade é opcional.
Ao solicitar o token dos serviços Live, sempre solicite o wl.basic escopo.
google {"id_token":"<id_token>"} A authorization_code propriedade é opcional. Fornecer um authorization_code valor adicionará um token de acesso e um token de atualização ao armazenamento de tokens. Quando especificado, authorization_code também pode opcionalmente ser acompanhado por uma redirect_uri propriedade.
facebook {"access_token":"<user_access_token>"} Use um token de acesso de usuário válido do Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

Nota

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

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.

{
    "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 ID 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"

Limitar o domínio das contas de início de sessão

Tanto a Conta Microsoft como o Microsoft Entra ID 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 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 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.

Importante

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

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 (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:

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