Considerações de alta disponibilidade no MSAL.NET

Para o fluxo de credenciais do cliente, consulte primeiro a documentação de Fluxos de credenciais do cliente.

Usar uma API de nível superior

MSAL é uma API de nível inferior. Se você estiver escrevendo um novo aplicativo, considere usar o nível Microsoft.Identitity.Web superior que fornece integração pronta para uso com ASP.NET Core e ASP.NET Clássico.

Use a versão mais recente do MSAL

Use a MSAL mais recente para obter as correções de bug e melhorias de desempenho. As regras de controle de versão semântica são seguidas.

Você também deve verificar se deve usar o Microsoft Identity Web, uma biblioteca de alto nível para aplicativos Web e APIs Web, que faz grande parte do que é descrito abaixo para você. Consulte Escolher uma versão do MSAL.NET, que propõe uma árvore de decisão para escolher a melhor solução, dependendo de sua plataforma e restrições.

Usar o cache de token

Comportamento padrão: A MSAL armazena em cache os tokens na memória. Cada ConfidentialClientApplication instância tem seu próprio cache de token interno. O cache na memória pode ser perdido, por exemplo, se a instância do objeto for descartada ou todo o aplicativo for interrompido.

Recomendação: Todos os aplicativos devem persistir seus caches de token. Aplicativos Web e APIs Web devem usar um cache de token L1/L2 em que L2 é um repositório distribuído como o Redis para lidar com a escala. Os aplicativos para desktop devem usar uma estratégia adequada de serialização de cache de tokens.

Note

Se você usar o Microsoft.Identity.Web, não precisará se preocupar com o cache, pois ele implementa por padrão o comportamento correto de cache. Se você não usar Microsoft. Identity.Web, mas está criando um aplicativo Web ou uma API Web, você gostaria de considerar uma abordagem híbrida

Comportamento padrão: A MSAL mantém um cache de token ADAL secundário para cenários de migração entre a ADAL e a MSAL. As operações de cache da ADAL são muito lentas. Recomendação: Desabilite o cache ADAL se você não estiver interessado em migrar da ADAL. Isso trará uma GRANDE melhoria de desempenho — veja as medições de desempenho aqui.

Adicione WithLegacyCacheCompatibility(false) ao construir seu aplicativo para desabilitar o cache ADAL.

Adicionar monitoramento às operações do MSAL

A MSAL expõe métricas importantes como parte do objeto AuthenticationResult.AuthenticationResultMetadata :

Métrica Meaning Quando disparar um alarme?
DurationTotalInMs Tempo total gasto na MSAL, incluindo chamadas de rede e cache Alarme para latência geral alta (> 1 s). O valor depende da origem do token. Do cache: um acesso de cache. Do Microsoft Entra ID: dois acessos ao cache + uma chamada HTTP. A primeira chamada (por processo) levará mais tempo devido a uma chamada HTTP extra.
DurationInCacheInMs Tempo gasto carregando ou salvando o cache de token, que é personalizado pelo desenvolvedor do aplicativo (por exemplo, salve no Redis). Alarme em picos.
DurationInHttpInMs Tempo gasto fazendo chamadas HTTP para Microsoft Entra ID. Alarme em picos.
TokenSource Indica a origem do token. Os tokens são recuperados do cache muito mais rápido (por exemplo, ~100 ms versus ~700 ms). Pode ser usado para monitorar e emitir alerta sobre a taxa de acertos do cache. Usar com o DurationTotalInMs.
CacheRefreshReason Especifica o motivo para buscar o token de acesso do provedor de identidade. Veja os valores possíveis. Usar com o TokenSource.

Logging

Ouça as mensagens de nível Warning e Error provenientes dos logs do MSAL. Podem ser erros silenciosos ou fortes recomendações para usar uma configuração diferente. Não é recomendável configurar o registro em log Verbose em produção, pois gera muitas mensagens e afeta o desempenho.

Os detalhes sobre o registro em log podem ser encontrados no guia de Registro em log no MSAL.NET.

Política de repetição

Comportamento padrão: a MSAL tentará novamente as solicitações 5xx que falharam uma vez.

Recomendação:

Um cliente confidencial por sessão

É recomendável usar um novo ConfidentialClientApplication em cada sessão e serializar da mesma maneira : um cache de token por sessão. Isso é escalável e também aumenta a segurança. Os exemplos oficiais mostram como fazer isso. Você deve configurar o cache de token para que isso funcione corretamente.

Note

Microsoft.Identity.Web aplica essa abordagem – uma instância de aplicativo cliente confidencial por solicitação com cache de token habilitado.

Cliente HTTP

Comportamento padrão: o HttpClient criado pela MSAL não escala bem para sites da Web/APIs da Web, nos quais recomendamos ter um objeto ClientApplication para cada sessão do usuário.

Recomendação: Forneça sua própria HttpClientFactory escalável. No .NET Core, recomendamos que você injete o Sistema.Net. Http.IHttpClientFactory. Isso é descrito com mais detalhes no guia Fornecer seu próprio HttpClient, suporte a proxies HTTP e personalização de cabeçalhos de agente de usuário e na documentação do .NET

Renovação proativa do token

Goal

Aumente a disponibilidade do aplicativo emitindo tokens de acesso mais longos e verifique se eles são atualizados antes da data de validade.

Status quo

Por padrão, Microsoft Entra ID emite tokens de acesso com expiração de 1 hora. Se uma interrupção Microsoft Entra ocorrer quando um token precisar ser atualizado, a MSAL falhará. A falha se propaga para o aplicativo de chamada e afeta a disponibilidade.

Processo

Para melhorar a disponibilidade, a MSAL tenta garantir que um aplicativo sempre tenha tokens novos não expirados. Microsoft Entra interrupções raramente levam mais de algumas horas, portanto, se a MSAL puder garantir que um token sempre tenha pelo menos algumas horas de disponibilidade restantes, o aplicativo não será afetado pela interrupção do Microsoft Entra.

Para obter tokens de longa duração, você deve configurar seu locatário (observação: locatários internos da Microsoft já estão configurados). Para client_credentials (serviço a serviço), isso é suficiente. Para credenciais do usuário, você também deve configurar a CAE - /azure/active-directory/conditional-access/concept-continuous-access-evaluation.

Quando Microsoft Entra ID retorna um token de vida longa, ele inclui um refresh_in campo. Geralmente, ele é definido como metade da expiração do token de acesso.

Rastreamento no Fiddler de uma solicitação de token de acesso

Observação: A partir do MSAL 4.37.0, você pode verificar esse valor inspecionando o AuthenticationResult.AuthenticationResultMetadata.RefreshOn.

Além disso, você pode configurar um tempo de vida de token superior ao padrão de 1 hora, conforme descrito nos tempos de vida do token configurável no plataforma de identidade da Microsoft (versão prévia).

Sempre que você fizer solicitações para o mesmo token, ou seja, sempre que a MSAL puder servir um token de seu cache, a MSAL verificará automaticamente o refresh_in valor. Se esse prazo tiver expirado, a MSAL fará uma solicitação de token ao Microsoft Entra ID em segundo plano, mas retornará o token válido existente para o aplicativo. Na improvável hipótese de que a atualização em segundo plano falhe (por exemplo, devido a uma indisponibilidade do Microsoft Entra), o aplicativo não será afetado.

Rotação de certificados

Os certificados do aplicativo cliente confidencial devem ser rotacionados por motivos de segurança (não use segredos em produção!). Há várias maneiras de lidar com a rotação de certificados, na ordem das mais preferenciais ao mínimo:

  1. Usar identidade gerenciada

Com a identidade gerenciada, a confiança é estabelecida por meio da hospedagem do aplicativo em Azure. Não há segredos para gerenciar nem certificados para rotacionar.

  1. Usar a lógica de tratamento de certificados Microsoft.Identity.Web

Em aplicativos web e APIs web, use Microsoft.Identity.Web, uma API de mais alto nível sobre o MSAL. Ele lida com a rotação de certificados quando o certificado é armazenado em Azure Key Vault e lida com o caso de identidade gerenciada também.

Saiba mais no guia Certificates in Microsoft.Identity.Web.

Essa é a solução preferencial para serviços internos não Microsoft usando ASP.NET Core.

  1. (Somente para uso interno da Microsoft) Use certificados de Nome do Titular/Emissor.

Esse mecanismo permite que Microsoft Entra ID identifique um certificado com base em SN/I em vez de uma impressão digital (x5t). É uma solução de stop-gap; não há planos para disponibilizá-lo para aplicativos não Microsoft.

Essa é a solução preferencial para Microsoft serviços internos que não podem usar a identidade gerenciada.

  • Last updated on