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

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.

• Microsoft Entra ID
• Facebook
• GitHub
• Google
• X
• Conexão OpenID personalizada

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.

A funcionalidade de autenticação incorporada do Container Apps permite-lhe poupar tempo e esforço, ao disponibilizar autenticação pré-configurada com fornecedores 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 X.

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:

Quando utiliza um destes fornecedores, o ponto final de início de sessão está disponível para autenticação do utilizador e validação do token de autenticação do fornecedor. 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 funcionalidades

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.

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. A delegação é normalmente utilizada em aplicações de navegador, que apresentam ao utilizador a página de início de sessão do fornecedor.

• 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 uma aplicação de browser fidedigna no Container Apps para outra API REST no Container Apps podem ser autenticadas através do fluxo orientado pelo servidor. Para obter mais informações, consulte Personalizar o início de sessão e o fim de sessão.

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

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 pedidos autenticados, o Container Apps também transmite 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 autenticaçã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 o pedido anónimo vier de uma aplicação móvel nativa, a resposta será um HTTP 401 Unauthorized. 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 granular, como a autorização específica por função, pode ser gerida inspecionando as declarações do utilizador (consulte Aceder às declarações do utilizador).

  Atenção

  Restringir o acesso ao seu aplicativo se aplica a todas as solicitações ao seu aplicativo. Essas restrições podem não ser preferíveis para aplicativos com uma página da Web disponível publicamente, como é típico em muitos aplicativos de página única.

  Nota

  Por predefinição, qualquer utilizador no seu inquilino do Microsoft Entra pode pedir um token para a sua aplicação a partir do Microsoft Entra ID. 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 o fim de sessão

A Autenticação das Container Apps fornece pontos de extremidade incorporados para iniciar e terminar sessão. Quando a funcionalidade está ativada, estes pontos de extremidade ficam disponíveis no prefixo de rota /.auth na sua aplicação de contentor.

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 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/x">Log in with X</a>

Quando o utilizador seleciona uma das ligações, a interface de utilizador dos respetivos fornecedores é apresentada ao utilizador.

Para redirecionar o utilizador, após iniciar sessão, para um URL personalizado, utilize o parâmetro de cadeia de consulta post_login_redirect_uri (não confundir com o URI de redirecionamento na configuração do seu fornecedor de identidade). Por exemplo, para direcionar o utilizador para /Home/Index após iniciar sessão, utilize o seguinte código HTML:

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

Início de sessão iniciado pelo cliente

Num início de sessão orientado pela aplicação cliente, a aplicação autentica o utilizador junto do fornecedor de identidade através de um SDK específico desse fornecedor. 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. Durante a execução, depois de recuperar o token de autenticação do seu fornecedor, envie o token para /.auth/login/<provider> para 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:

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 utilizadores podem terminar sessão enviando um GET pedido para a extremidade /.auth/logout da aplicação. 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. Pode alterar a página de redirecionamento após terminar sessão adicionando o parâmetro de consulta post_logout_redirect_uri. 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.

Aceder às declarações do utilizador no código da aplicação

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.

Além destes cabeçalhos de identidade, a sua aplicação pode aceder a tokens de autenticação (como tokens de acesso Microsoft Entra) através de cabeçalhos de pedido como X-MS-TOKEN-AAD-ACCESS-TOKEN. Para disponibilizar estes tokens, deve ativar a loja de tokens como parte das definições de autenticação da sua aplicação container. Uma vez ativados, os pedidos enviados à sua aplicação incluem cabeçalhos adicionais relacionados com tokens, dependendo do fornecedor de identidade configurado e do fluxo de autenticação.

Endpoints seguros com EasyAuth

Ao proteger os endpoints com a autenticação Azure Container Apps, é necessário registar uma aplicação com o Microsoft Entra ID e configurar as definições de autenticação.

Siga estes passos para configurar um acesso seguro:

1. Criar registo de aplicações do Azure AD

   az ad app create \
     --display-name <APP_DISPLAY_NAME> \
     --sign-in-audience AzureADMyOrg
   ---
   
   

2. Ative a aplicação para emitir tokens de identificação. Este passo é obrigatório para o suporte de Autenticação Fácil.

   az ad app update \
     --id <APPLICATION_ID> \
     --enable-id-token-issuance true
   

3. Adicione a URL de redirecionamento para o callback do Easy Auth.

   az ad app update \
     --id <APP_ID> \
     --web-redirect-uris "https://<APP-NAME>.<ENVIRONMENT-NAME>.<REGION>.azurecontainerapps.io/.auth/login/aad/callback"
   ---
   
   

4. Gerar um segredo do cliente

   az ad app credential reset \
     --id <APP_ID>" \
     --display-name "<APP_NAME>-Secret"
   ---
   
   

5. Crie o principal de serviço para a sua aplicação.

   az ad sp create --id <APP_ID>
   ---
   
   

6. Configure a sua aplicação de contentores para usar autenticação Microsoft Entra ID.

   Certifique-se de que o valor que fornece para o <APP_NAME> marcador é o nome da aplicação que configurou para funcionar com o EasyAuth.

   az containerapp auth microsoft update \
     --name <APP_NAME> \
     --resource-group <RESOURCE_GROUP> \
     --client-id <APP_ID> \
     --client-secret <CLIENT_SECRET> \
     --tenant-id <TENANT_ID> \
     --yes
   

Próximos passos

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

• Microsoft Entra ID
• Facebook
• GitHub
• Google
• X
• Conexão OpenID personalizada