Considérations relatives à la haute disponibilité dans MSAL.NET

Pour le flux d’informations d’identification du client, consultez la documentation des flux d’informations d’identification du client en premier.

Utiliser une API de niveau supérieur

MSAL est une API de niveau inférieur. Si vous écrivez une nouvelle application, envisagez d’utiliser le niveau Microsoft.Identitity.Web supérieur qui fournit une intégration prête à l’emploi avec ASP.NET Core et ASP.NET Classique.

Utiliser la dernière version de MSAL

Utilisez la dernière version de MSAL pour obtenir les correctifs de bogues et les améliorations des performances. Les règles de contrôle de version sémantique sont suivies.

Vous souhaiterez également vérifier si vous devriez utiliser Microsoft Identity Web, une bibliothèque de plus haut niveau pour les applications web et les API web, qui prend en charge une grande partie de ce qui est décrit ci-dessous pour vous. Consultez Choisir une version de MSAL.NET, qui propose un arbre de décision pour choisir la meilleure solution en fonction de votre plateforme et de vos contraintes.

Utiliser le cache de jetons

Comportement par défaut : MSAL met en cache les jetons en mémoire. Chaque ConfidentialClientApplication instance a son propre cache de jeton interne. Le cache en mémoire peut être perdu, par exemple, si l’instance d’objet est supprimée ou si l’application entière est arrêtée.

Recommandation: Toutes les applications doivent conserver leurs caches de jetons. Les applications web et les API web doivent utiliser un cache de jetonS L1/L2 où L2 est un magasin distribué comme Redis pour gérer l’échelle. Les applications de bureau doivent utiliser une stratégie de sérialisation de cache de jeton appropriée.

Note

Si vous utilisez Microsoft. Identity.Web, vous n'avez pas besoin de vous soucier du cache car il implémente le bon comportement de cache prête à l'emploi. Si vous n'utilisez pas Microsoft. Identity.Web, mais qui crée une application web ou une API web, vous souhaitez envisager une approche hybride

Comportement par défaut : MSAL gère un cache de jeton ADAL secondaire pour les scénarios de migration entre ADAL et MSAL. Les opérations de cache ADAL sont très lentes. Recommandation: Désactivez le cache ADAL si vous n’êtes pas intéressé par la migration à partir d’ADAL. Cela apportera une grosse amélioration des performances - voir les mesures de performances ici.

Ajoutez WithLegacyCacheCompatibility(false) lors de la construction de votre application pour désactiver la mise en cache ADAL.

Ajouter une surveillance autour des opérations MSAL

MSAL expose des métriques importantes dans le cadre de l’objet AuthenticationResult.AuthenticationResultMetadata :

Metric	Sens	Quand déclencher une alarme ?
DurationTotalInMs	Temps total passé dans MSAL, y compris les appels réseau et le cache	Alarme sur une latence élevée globale (> 1 s). La valeur dépend de la source du jeton. Depuis le cache : un accès au cache. À partir de Microsoft Entra ID : deux accès au cache + un appel HTTP. Le premier appel (par processus) prendra plus de temps en raison d’un appel HTTP supplémentaire.
DurationInCacheInMs	Temps passé au chargement ou à l’enregistrement du cache de jetons, personnalisé par le développeur de l’application (par exemple, enregistrer dans Redis).	Alarme en cas de pic.
DurationInHttpInMs	Temps passé à effectuer des appels HTTP à Microsoft Entra ID.	Alarme lors de pics.
TokenSource	Indique la source du jeton. Les jetons sont récupérés à partir du cache beaucoup plus rapidement (par exemple, ~100 ms par rapport à ~700 ms). Peut être utilisé pour surveiller et alarmer le taux d’accès au cache.	Utiliser avec DurationTotalInMs.
CacheRefreshReason	Spécifie la raison de la récupération du jeton d’accès auprès du fournisseur d’identité. Voir les valeurs possibles.	Utiliser avec TokenSource.

Logging

Écoutez les messages de niveau Warning et Error provenant des journaux MSAL. Il peut s’agir d’erreurs silencieuses ou de recommandations fortes pour utiliser une autre configuration. Il n’est pas recommandé de définir Verbose la journalisation en production, car elle produit beaucoup de messages et a un impact sur les performances.

Vous trouverez des détails sur la journalisation dans le guide de journalisation dans MSAL.NET.

Stratégie de nouvelle tentative

Comportement par défaut : MSAL réessaye les demandes 5xx ayant échoué une seule fois.

Recommandation :

• Consultez notre documentation sur la stratégie de nouvelle tentative pour définir une stratégie de nouvelle tentative avec Polly

Un client confidentiel par session

Il est recommandé d’utiliser un nouveau ConfidentialClientApplication sur chaque session et de sérialiser de la même façon : un cache de jetons par session. L’évolutivité est alors bonne, avec une augmentation de la sécurité. Les exemples officiels montrent comment procéder. Vous devez configurer la mise en cache des jetons pour que cela fonctionne correctement.

Note

Microsoft.Identity.Web applique cette approche : une instance d’application cliente confidentielle par requête avec mise en cache de jeton activée.

HttpClient

Comportement par défaut : l’élément HttpClient créé par MSAL ne passe pas bien à l’échelle pour les sites web et API web, pour lesquels nous recommandons d’avoir un objet ClientApplication pour chaque session utilisateur.

Recommandation : fournissez votre propre httpClientFactory scalable. Sur .NET Core, nous vous recommandons d’injecter le System.Net.Http.IHttpClientFactory. Ceci est décrit plus en détail dans le guide de fourniture de votre propre httpClient, prise en charge des proxys HTTP et personnalisation des en-têtes d’agent utilisateur et dans la documentation .NET

Renouvellement proactif des jetons

Objectif

Augmentez la disponibilité des applications en émettant des jetons d’accès plus longs et en vous assurant qu’ils sont actualisés avant leur date d’expiration.

Statu quo

Par défaut, Microsoft Entra ID émet des jetons d’accès avec une expiration d’une heure. Si une panne de Microsoft Entra se produit lorsqu’un jeton doit être actualisé, MSAL échoue. L’échec se propage à l’application appelante et affecte la disponibilité.

Processus

Pour améliorer la disponibilité MSAL tente de s’assurer qu’une application a toujours des jetons non expirés. Les pannes de Microsoft Entra durent rarement plus de quelques heures ; ainsi, si MSAL peut garantir qu’un jeton dispose toujours d’au moins quelques heures de validité restantes, l’application ne sera pas affectée par une panne de Microsoft Entra.

Pour obtenir des jetons à longue durée de vie, vous devez configurer votre locataire (remarque : les locataires internes de Microsoft sont déjà configurés). Pour client_credentials (service 2), cela suffit. Pour les informations d’identification utilisateur, vous devez également configurer CAE : /azure/active-directory/conditional-access/concept-continuous-access-evaluation.

Lorsque Microsoft Entra ID renvoie un jeton à longue durée de vie, il inclut un champ refresh_in. Il est généralement réglé sur la moitié de la durée de validité du jeton d’accès.

Remarque : À partir de MSAL 4.37.0 et versions ultérieures, vous pouvez observer cette valeur en inspectant le AuthenticationResult.AuthenticationResultMetadata.RefreshOn.

En outre, vous pouvez configurer une durée de vie de jeton de plus de 1 heure par défaut, comme décrit dans les durées de vie des jetons configurables dans la Plateforme d'identités Microsoft (préversion).

Chaque fois que vous effectuez des demandes pour le même jeton, c’est-à-dire chaque fois que MSAL est en mesure de servir un jeton à partir de son cache, MSAL vérifie automatiquement la refresh_in valeur. S’il a expiré, MSAL enverra une demande de jeton à Microsoft Entra ID en arrière-plan, mais renverra à l’application le jeton existant encore valide. Dans le cas peu probable où l’actualisation en arrière-plan échoue (par exemple, Microsoft Entra panne), l’application n’est pas affectée.

Rotation des certificats

Les certificats de l’application cliente confidentielle doivent être pivotés pour des raisons de sécurité (n’utilisez pas de clés secrètes dans un environnement de production !). Il existe plusieurs façons de gérer la rotation des certificats, dans l’ordre le plus préféré au moins :

1. Utiliser l’identité managée

Avec l’identité managée, l’approbation est établie via l’hébergement de votre application dans Azure. Il n’y a pas de secrets à gérer ni de certificats à renouveler.

2. Utiliser la logique de Microsoft.Identity.Web gestion des certificats

Dans les applications web et les API web, utilisez Microsoft.Identity.Webune API de niveau supérieur sur MSAL. Il gère également la rotation des certificats lorsque le certificat est stocké dans Azure Key Vault et gère également le cas d’identité managée.

En savoir plus sur les certificats dans Microsoft. Guide Identity.Web.

Il s’agit de la solution recommandée pour les services internes non Microsoft à l’aide de ASP.NET Core.

3. (Microsoft interne uniquement) S’appuyer sur les certificats de nom du sujet/de l’émetteur.

Ce mécanisme permet Microsoft Entra ID d’identifier un certificat basé sur SN/I au lieu d’une empreinte numérique (x5t). Il s’agit d’une solution provisoire ; il n’est pas prévu de la rendre disponible pour des applications autres que celles de Microsoft.

Il s’agit de la solution recommandée pour Microsoft services internes qui ne peuvent pas utiliser l’identité managée.