Partilhar via

Autenticação e autorização em Aplicativos de Contêiner do Azure

  • Artigo

Os Aplicativos de Contêiner do Azure fornecem recursos internos de autenticação e autorização (às vezes chamados de "Autenticação Fácil"), para proteger seu aplicativo de contêiner externo habilitado para entrada com pouco ou nenhum código.

Para obter detalhes sobre autenticação e autorização, consulte os guias a seguir para sua escolha de provedor.

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, 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 Aplicativos de Contêiner economiza tempo e esforço ao fornecer autenticação pronta para uso com provedores de identidade federada. Esses recursos permitem que você se concentre mais tempo desenvolvendo seu aplicativo e menos tempo na criação de sistemas de segurança.

Os benefícios incluem:

  • Os Aplicativos de Contêiner do Azure fornecem acesso a vários provedores de autenticação internos.
  • Os recursos de autenticação integrados não exigem nenhuma linguagem específica, SDK, experiência em segurança ou até mesmo qualquer código que você tenha que escrever.
  • Você pode integrar com vários provedores, incluindo Microsoft Entra ID, Facebook, Google e Twitter.

Fornecedores de identidade

Os Aplicativos de Contêiner usam 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
Plataforma de identidade da Microsoft /.auth/login/aad Plataforma de identidade da Microsoft
Facebook /.auth/login/facebook Facebook
GitHub /.auth/login/github GitHub
Google /.auth/login/google Google
Twitter /.auth/login/twitter Twitter
Qualquer provedor OpenID Connect /.auth/login/<providerName> OpenID Connect

Quando você usa um desses provedores, o ponto de extremidade de entrada fica disponível para autenticação de usuário e validação de token de autenticação do provedor. Você pode fornecer aos usuários qualquer número dessas opções de provedor.

Considerações sobre o uso da autenticação interna

Este recurso deve ser usado apenas com HTTPS. Verifique se allowInsecure está desabilitado na configuração de entrada do seu aplicativo de contêiner.

Você pode configurar seu aplicativo de contêiner para autenticação com ou sem restringir o acesso ao conteúdo do site e às APIs. Para restringir o acesso ao aplicativo apenas a usuários autenticados, defina a configuração Restringir acesso como Exigir autenticação. Para autenticar, mas não restringir o acesso, defina a configuração Restringir acesso como Permitir acesso não autenticado.

Por padrão, cada aplicativo de contêiner emite seu próprio cookie ou token exclusivo para autenticação. Você também pode fornecer suas próprias chaves de assinatura e criptografia.

Arquitetura de recursos

O componente middleware de autenticação e autorização é um recurso da plataforma que é executado como um contêiner sidecar em cada réplica em seu aplicativo. Quando habilitado, seu aplicativo lida com cada solicitação HTTP de entrada depois que ela passa pela camada de segurança.

Um diagrama de arquitetura mostrando solicitações sendo intercetadas por um contêiner sidecar que interage com provedores de identidade antes de permitir o tráfego para o contêiner do aplicativo

O middleware da plataforma lida com várias coisas para seu aplicativo:

  • Autentica usuários e clientes com os provedores de identidade especificados
  • Gerencia a sessão autenticada
  • Injeta informações de identidade em cabeçalhos de solicitação HTTP

O módulo de autenticação e autorização é executado em um contêiner separado, isolado do código do aplicativo. Como o contêiner de segurança 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 fornecidas nos cabeçalhos de solicitação, conforme explicado neste artigo.

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 (fluxo direcionado ao servidor ou fluxo do servidor): o aplicativo delega a entrada federada aos Aplicativos de Contêiner. Normalmente, a delegação é o caso dos aplicativos do navegador, que apresentam a página de entrada do provedor ao usuário.

  • Com o SDK do provedor (fluxo direcionado ao cliente ou fluxo do cliente): o aplicativo conecta os usuários ao provedor manualmente e, em seguida, envia o token de autenticação para Aplicativos de Contêiner para validação. Essa abordagem é típica de aplicativos sem navegador que não apresentam a página de entrada do provedor ao usuário. Um exemplo é um aplicativo móvel nativo que conecta usuários usando o SDK do provedor.

As chamadas de um aplicativo de navegador confiável em Aplicativos de Contêiner para outra API REST em Aplicativos de Contêiner podem ser autenticadas usando o fluxo direcionado ao servidor. Para obter mais informações, consulte Personalizar entrada e sair.

A tabela 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 Container Apps adiciona cookie autenticado à resposta. Container Apps 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, os Aplicativos de Contêiner podem 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

No portal do Azure, você pode editar as configurações de autenticação do seu aplicativo de contêiner para configurá-lo com vários comportamentos quando uma solicitação de entrada não é autenticada. Os títulos seguintes descrevem as opções.

  • Permitir acesso não autenticado: esta opção adia a autorização de tráfego não autenticado para o código do aplicativo. Para solicitações autenticadas, os Aplicativos de Contêiner também passam informações de autenticação nos cabeçalhos HTTP. Seu aplicativo pode usar informações nos cabeçalhos para tomar decisões de autorização para uma solicitação.

    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 rejeita qualquer tráfego não autenticado para o seu aplicativo. Essa rejeição pode ser uma ação de redirecionamento para um dos provedores de identidade configurados. Nesses casos, um cliente de navegador é redirecionado para o provedor escolhido /.auth/login/<PROVIDER> . 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 como um HTTP 401 Unauthorized ou HTTP 403 Forbidden para todas as solicitações.

    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

    Por padrão, qualquer usuário em seu locatário do Microsoft Entra pode solicitar um token para seu aplicativo da ID do Microsoft Entra. Pode configurar a aplicação no Microsoft Entra ID se quiser restringir o acesso à sua aplicação a um conjunto definido de utilizadores.

Personalizar o início de sessão e terminar sessão

A Autenticação de Aplicativos de Contêiner fornece pontos de extremidade internos para entrar e sair. Quando o recurso está habilitado, esses pontos de extremidade ficam disponíveis sob o prefixo de /.auth rota em seu aplicativo de contêiner.

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>

Quando o usuário seleciona em um dos links, a interface do usuário dos respetivos provedores é exibida para o 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 para Aplicativos de Contêiner para validação (consulte Fluxo de autenticação) usando uma solicitação HTTP POST.

Para validar o token do provedor, o aplicativo de contêiner 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://<hostname>.azurecontainerapps.io/.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 adiciona um token de acesso e um token de atualização ao repositório 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":"<ACCES_TOKEN_SECRET>"}

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://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Sair de uma sessão

Os usuários podem sair enviando uma GET solicitação para o ponto de /.auth/logout extremidade do aplicativo. O GET pedido realiza as seguintes ações:

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

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

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

Por padrão, um logout bem-sucedido redireciona o cliente para a URL /.auth/logout/done. 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

Certifique-se de codificar o valor de post_logout_redirect_uri.

A URL deve ser hospedada no mesmo domínio ao usar URLs totalmente qualificadas.

Acessar declarações de usuário no código do aplicativo

Para todas as estruturas de linguagem, o Container Apps disponibiliza as declarações no token de entrada para o código do seu aplicativo. As declarações são injetadas nos cabeçalhos de solicitação, que estão presentes seja de um usuário final autenticado ou de um aplicativo cliente. As solicitações externas não têm permissão para definir esses cabeçalhos, portanto, eles estão presentes apenas se definidos por Aplicativos de Contêiner. Alguns exemplos de cabeçalhos incluem:

  • X-MS-CLIENT-PRINCIPAL-NAME
  • X-MS-CLIENT-PRINCIPAL-ID

O código escrito em qualquer linguagem ou estrutura pode obter as informações necessárias a partir desses cabeçalhos.

Nota

Diferentes estruturas de linguagem podem apresentar esses cabeçalhos para o código do aplicativo em formatos diferentes, como minúsculas ou minúsculas.

Próximos passos

Consulte os seguintes artigos para obter detalhes sobre como proteger seu aplicativo de contêiner.