Considerações de alta disponibilidade no MSAL.NET

Para o fluxo de credenciais de cliente, consulte primeiro a documentação sobre fluxos de credenciais de cliente.

Use uma API de nível superior

O MSAL é uma API de nível inferior. Se estiveres a escrever uma nova aplicação, considera usar o nível Microsoft.Identitity.Web superior, que oferece integração pronta a usar com ASP.NET Core e ASP.NET Classic.

Use o MSAL mais recente

Use o MSAL mais recente para obter correções de bugs e melhorias de desempenho. Seguem-se regras semânticas de versionamento.

Também deve verificar se deve usar o Microsoft Identity Web, uma biblioteca de nível superior para aplicações web e APIs web, que faz muito do que é descrito abaixo para si. Veja Escolher uma versão do MSAL.NET, que propõe uma árvore de decisão para escolher a melhor solução consoante a sua plataforma e restrições.

Usar a cache de tokens

Comportamento padrão: O MSAL armazena os tokens em memória. Cada ConfidentialClientApplication instância tem a sua própria cache interna de tokens. A cache em memória pode ser perdida, por exemplo, se a instância do objeto for eliminada ou se toda a aplicação for parada.

Recomendação: Todas as aplicações devem manter as suas caches de tokens. As aplicações web e as APIs Web devem usar uma cache de tokens L1 / L2, onde a L2 é uma loja distribuída como a Redis para gerir a escala. As aplicações de ambiente de trabalho devem usar uma estratégia adequada de serialização da cache de tokens.

Comportamento padrão: A MSAL mantém uma cache secundária de tokens ADAL para cenários de migração entre ADAL e MSAL. As operações de cache ADAL são muito lentas. Recomendação: Desative a cache ADAL se não estiver interessado em migrar a partir do ADAL. Isto vai trazer uma GRANDE melhoria de desempenho – veja as medições de desempenho aqui.

Adicione WithLegacyCacheCompatibility(false) ao construir a sua aplicação para desativar o cache ADAL.

Adicionar monitorização em torno das operações MSAL

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

Logging

Monitorize mensagens de nível Warning e Error provenientes dos registos do MSAL. Podem ser erros silenciosos ou recomendações fortes para usar uma configuração diferente. Não é recomendado definir Verbose o registo em produção, pois gera muitas mensagens e afeta a performance.

Detalhes sobre o registo podem ser consultados no guia Registo no MSAL.NET.

Política de repetição de tentativas

Comportamento padrão: O MSAL tenta novamente pedidos 5xx falhados uma vez.

Recomendação:

• Consulte a nossa documentação sobre a política de repetição para escrever uma política de repetição com Polly

Um Cliente Confidencial por sessão

Recomenda-se usar um novo ConfidentialClientApplication em cada sessão e serializar da mesma forma – um token cache por sessão. Isso é facilmente escalável e também aumenta a segurança. Os exemplos oficiais mostram como fazer isto. Tens de configurar o cache de tokens para que isto funcione corretamente.

HttpClient

Comportamento predefinido: o HttpClient criado pelo MSAL não é muito escalável para sites Web/APIs Web, onde recomendamos que exista um objeto ClientApplication para cada sessão de utilizador.

Recomendação: Fornece o teu próprio HttpClientFactory escalável. No .NET Core, recomendamos que utilize a injeção de System.Net.Http.IHttpClientFactory. Isto é descrito mais detalhadamente no guia Fornecer o seu próprio HttpClient, suporte a proxies HTTP e personalização dos cabeçalhos do agente do utilizador e na documentação do .NET

Renovação proativa de tokens

Goal

Aumente a disponibilidade das aplicações emitindo tokens de acesso de maior duração e assegure que são atualizados antes da data de expiração.

Status quo

Por predefinição, o Microsoft Entra ID emite tokens de acesso com uma expiração de 1 hora. Se ocorrer uma falha do Microsoft Entra quando um token precisa de ser atualizado, a MSAL falhará. A falha propaga-se para a aplicação que chama e afeta a disponibilidade.

Processo

Para melhorar a disponibilidade, a MSAL tenta garantir que uma aplicação tenha sempre tokens frescos e não expirados. As falhas do Microsoft Entra raramente demoram mais do que algumas horas, por isso, se a MSAL puder garantir que um token tem sempre pelo menos algumas horas de disponibilidade, a aplicação não será afetada pela falha do Microsoft Entra.

Para obter tokens de longa duração, tem de configurar o seu tenant (nota: os tenants internos da Microsoft já estão configurados). Para client_credentials (serviço 2), isto é suficiente. Relativamente às credenciais de utilizador, deve também configurar CAE - /azure/active-directory/conditional-access/concept-continuous-access-evaluation.

Quando o Microsoft Entra ID devolve um token de longa duração, inclui um campo refresh_in. É geralmente definido para metade da expiração do token de acesso.

Nota: A partir da versão 4.37.0 do MSAL e posteriores, pode observar este valor ao inspecionar o AuthenticationResult.AuthenticationResultMetadata.RefreshOn.

Além disso, pode configurar um tempo de vida de token superior ao valor predefinido de 1 hora, conforme descrito em Tempos de vida de token configuráveis na plataforma de identidades da Microsoft (pré-visualização).

Sempre que fizer pedidos pelo mesmo token, ou seja, sempre que a MSAL consegue servir um token a partir da sua cache, a MSAL verifica automaticamente o refresh_in valor. Se tiver expirado, a MSAL emitirá um pedido de token para o Microsoft Entra ID em segundo plano, mas devolverá o token existente e válido à aplicação. No improvável caso de a atualização em segundo plano falhar (por exemplo, uma falha da Microsoft Entra), a aplicação não é afetada.

Rotação de Certificados

Os certificados da aplicação cliente confidencial têm de ser renovados por razões de segurança (não utilize segredos em produção!). Existem várias formas de gerir a rotação de certificados, por ordem da mais preferida à menos favorável:

1. Utilizar a identidade gerida

Com a identidade gerida, a confiança é estabelecida através do alojamento da sua aplicação no Azure. Não há segredos para gerir nem certificados para renovar.

2. Utilizar a lógica de gestão de certificados Microsoft.Identity.Web

Em aplicações web e APIs web, use Microsoft.Identity.Web, uma API de nível superior sobre MSAL. Trata da rotação de certificados quando o certificado está armazenado no Azure Key Vault e também trata de casos de identidade gerida.

Saiba mais no guia Certificados no Microsoft.Identity.Web.

Esta é a solução preferida para serviços internos não da Microsoft que utilizam o ASP.NET Core.

3. (Apenas para uso interno da Microsoft) Utiliza certificados de Nome do Sujeito/Emissor.

Este mecanismo permite que o Microsoft Entra ID identifique um certificado com base no SN/I em vez de uma impressão digital (x5t). É uma solução provisória; não há planos para o disponibilizar a aplicações que não sejam da Microsoft.

Esta é a solução preferida para serviços internos da Microsoft que não conseguem usar identidade gerida.