Compartilhar via

Autenticação e autorização nos 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 o aplicativo de contêiner habilitado para entrada externa com mínimo de código ou sem código.

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

Por que usar a autenticação interna?

Não é necessário usar esse recurso para autenticação e autorização. Você pode usar os recursos de segurança em pacote na estrutura Web de sua escolha ou escrever seus próprios utilitários. No entanto, implementar uma solução segura para autenticação (usuários conectados) e autorização (fornecendo acesso a dados seguros) poderá exigir um esforço significativo. Você deve se certificar de seguir as práticas recomendadas e os 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 federados. Esses recursos permitem que você dedique mais tempo ao desenvolvimento do aplicativo e menos tempo à 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 mesmo qualquer código que você precise gravar.
  • Você pode se integrar a vários provedores, incluindo Microsoft Entra ID, Facebook, Google e Twitter.

Provedores de identidade

Os Aplicativos de Contêiner usam identidade federada, em que um provedor de identidade de terceiros gerencia as identidades do usuário e o fluxo de autenticação para você. Os provedores de identidade a seguir estão disponíveis por padrão:

Provedor Ponto de extremidade de logon Diretrizes
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 do OpenID Connect /.auth/login/<providerName> OpenID Connect

Ao usar um desses provedores, o ponto de extremidade de entrada ficará disponível para a autenticação de usuário e a validação de token de autenticação do provedor. Você poderá fornecer a seus usuários qualquer número dessas opções de provedor.

Considerações ao usar a autenticação interna

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

É possível configurar o aplicativo de contêiner para autenticação com ou sem restringir o acesso ao conteúdo e às APIs do seu site. Para restringir o acesso ao aplicativo somente 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 criptografia e assinatura.

Arquitetura de recursos

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

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

O middleware de 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 da solicitação

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 executa em processo, nenhuma integração direta com estruturas de linguagem específicas será possível. Entretanto, 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 o SDK do provedor (fluxo direcionado pelo servidor ou fluxo de servidor): o aplicativo delega a entrada federada aos Aplicativos de Contêiner. A delegação é normalmente o caso de aplicativos de navegador, que apresentam a página de entrada do provedor ao usuário.

  • Com o SDK do provedor (fluxo direcionado pelo cliente ou fluxo de cliente): o aplicativo conecta os usuários ao provedor manualmente e, em seguida, envia o token de autenticação aos Aplicativos de Contêiner para validação. Essa abordagem é típica para 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 a entrada e a saída.

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

Etapa Sem SDK do provedor Com SDK do provedor
1. Conectar usuário Redireciona o cliente para /.auth/login/<PROVIDER>. O código do cliente coneta o usuário diretamente no 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 Provedor redireciona o cliente para /.auth/login/<PROVIDER>/callback. O código do cliente envia o token do provedor para /.auth/login/<PROVIDER> para a validação.
3. Estabelecer sessão autenticada Os Aplicativos de Contêiner adicionam um cookie autenticado à resposta. Os Aplicativos de Contêiner retornam seu próprio token de autenticação ao código do cliente.
4. Fornecer conteúdo autenticado O cliente inclui o cookie de autenticação em solicitações subsequentes (manipuladas automaticamente pelo navegador). O código do cliente apresenta o token de autenticação no cabeçalho X-ZUMO-AUTH.

Para navegadores do cliente, os Aplicativos de Contêiner podem direcionar automaticamente todos os usuários não autenticados para /.auth/login/<PROVIDER>. Você também pode apresentar aos usuários um ou mais links /.auth/login/<PROVIDER> para entrar no aplicativo usando o provedor escolhido.

Comportamento de autorização

No portal do Azure, é possível editar as configurações de autenticação do aplicativo de contêiner para configurá-lo com vários comportamentos quando uma solicitação recebida não for autenticada. Os cabeçalhos a seguir descrevem as opções.

  • Permitir acesso não autenticado: essa 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 transmitem as informações de autenticação nos cabeçalhos HTTP. Seu aplicativo poderá usar as informações nos cabeçalhos para tomar decisões de autorização para uma solicitação.

    Essa opção oferece mais flexibilidade no processamento de solicitações anônimas. Por exemplo, permite que você apresente vários provedores de entrada aos usuários. No entanto, é necessário gravar o código.

  • Exigir autenticação: essa opção rejeita qualquer tráfego não autenticado para 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 /.auth/login/<PROVIDER> para o provedor escolhido. Se a solicitação anônima originar-se de um aplicativo móvel nativo, a resposta retornada será HTTP 401 Unauthorized. Você também pode configurar a rejeição como HTTP 401 Unauthorized ou HTTP 403 Forbidden para todas as solicitações.

    Com essa opção, você não precisa gravar nenhum código de autenticação no aplicativo. Uma autorização mais precisa, como autorização específica de função, pode ser tratada inspecionando as declarações do usuário (consulte Acessar declarações do usuário).

    Cuidado

    Esse tipo de restrição de acesso se aplica a todas as chamadas ao aplicativo, o que pode não ser útil para aplicativos que desejam uma página inicial publicamente disponível, como muitos aplicativos de página única.

    Observação

    Por padrão, qualquer usuário em seu locatário do Microsoft Entra pode solicitar um token para seu aplicativo a partir do Microsoft Entra ID. Você pode configurar o aplicativo no Microsoft Entra ID para restringir o acesso ao seu aplicativo a um conjunto definido de usuários.

Personalizar a entrada e a saída

A autenticação de Aplicativos de Contêiner do Azure fornece pontos de extremidade internos para entrada e saída. Quando o recurso está habilitado, esses pontos de extremidade estão disponíveis sob o prefixo de rota /.auth no seu aplicativo de contêiner.

Usar vários provedores de entrada

A configuração do portal não oferece uma maneira prática turnkey para apresentar vários provedores de entrada aos usuários (como o Facebook e o Twitter). 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 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 um dos links, a UI dos respectivos provedores é exibida ao usuário.

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 aos Aplicativos de Contêiner para validação (consulte Fluxo de autenticação) usando uma solicitação HTTP POST.

Para validar o token do provedor, primeiro será necessário configurar o aplicativo de contêiner 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://<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. 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. O fornecimento de um valor authorization_code adiciona 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":"<ACCES_TOKEN_SECRET>"}

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.

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

Sair de uma sessão

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

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

Aqui está um link simples de desconexão em uma página da Web:

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

Por padrão, uma saída bem-sucedida redirecionará o cliente para a URL /.auth/logout/done. É 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

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 as declarações do usuário no código do aplicativo

Para todas as estruturas de linguagem, os Aplicativos de Contêiner disponibilizam as declarações no token de entrada para o código do 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 estarão presentes somente se definidos pelos Aplicativos de Contêiner. Alguns cabeçalhos de exemplo incluem:

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

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

Observação

Estruturas de linguagem diferentes podem apresentar os cabeçalhos para o código do aplicativo em diferentes formatos, como letras minúsculas ou de título.

Próximas etapas

Consulte os artigos a seguir para obter mais detalhes sobre como proteger o aplicativo de contêiner.