Augmenter la résilience de l’authentification et de l’autorisation dans les applications démon que vous développez

  • Article

Apprendre à utiliser la plateforme d’identités Microsoft et Microsoft Entra ID pour augmenter la résilience des applications démon. Trouver des informations sur les processus d’arrière-plan, les services, les applications serveur à serveur et les applications sans utilisateur.

Consultez Présentation de la plateforme d’identités Microsoft

Le diagramme suivant montre une application démon effectuant un appel vers la Plateforme d'identités Microsoft.

A daemon application making a call to Microsoft identity platform.

Identités gérées pour les ressources Azure

Si vous créez des applications démon sur Microsoft Azure, utilisez des identités managées pour les ressources Azure qui gèrent les secrets et les informations d’identification. La fonctionnalité améliore la résilience en gérant l’expiration des certificats, la rotation ou la confiance.

Voir Que sont les identités managées pour les ressources Azure ?

Les identités managées utilisent des jetons d'accès à durée de vie étendue et des informations provenant de la Plateforme d'identités Microsoft pour acquérir de nouveaux jetons avant l’expiration des plus anciens jetons. Votre application s’exécute pendant l’acquisition de nouveaux jetons.

Les identités managées utilisent des points de terminaison régionaux qui permettent d’éviter les défaillances hors région en consolidant les dépendances du service. Les points de terminaison régionaux servent à conserver le trafic dans une zone géographique. Par exemple, si votre ressource Azure est installée à WestUS2, tout le trafic reste à WestUS2.

Microsoft Authentication Library

Si vous développez des applications démon, sans utiliser d’identités managées, utilisez Bibliothèque d’authentification Microsoft (MSAL) pour l’authentification et l’autorisation. MSAL simplifie le processus de fourniture des informations d’identification du client. Votre application n’a, par exemple, pas besoin de créer et de signer des assertions de jetons Web JSON avec des informations d’identification basées sur un certificat.

Voir Vue d’ensemble de la Bibliothèque d’authentification Microsoft (MSAL)

Microsoft.Identity.Web pour les développeurs .NET

Si vous développez des applications démon sur ASP.NET Core, servez-vous de la bibliothèque Microsoft.Identity.Web pour faciliter l’autorisation. Elle comprend des méthodes de cache de jetons distribués pour les applications distribuées s’exécutant dans plusieurs régions.

En savoir plus :

Cache et stockage de jetons

Si vous n’utilisez pas MSAL pour l’authentification et l’autorisation, de meilleures pratiques pour la mise en cache et le stockage des jetons existent. MSAL implémente et respecte ces meilleures pratiques.

Une application acquiert des jetons auprès d’un fournisseur d’identité (IdP) pour autoriser l’application à appeler des API protégées. Lorsque votre application reçoit des jetons, la réponse avec les jetons contient une propriété expires\_in qui indique à l’application la durée de mise en cache et de réutilisation du jeton. Vérifiez que les applications utilisent la propriété expires\_in pour déterminer la durée de vie du jeton. Confirmez que l’application n’essaie pas de décoder un jeton d’accès à l’API. L’utilisation du jeton mis en cache empêche tout trafic inutile entre une application et la plateforme d’identité Microsoft. Les utilisateurs sont connectés à votre application pendant la durée de vie du jeton.

Codes d’erreur HTTP 429 et 5xx

Utilisez les sections suivantes pour en apprendre davantage sur les codes d’erreur HTTP 429 et 5xx

HTTP 429

Il existe des erreurs HTTP affectant la résilience. Si votre application reçoit un code d’erreur HTTP 429, Trop de requêtes, la Plateforme d'identités Microsoft limite vos requêtes, empêchant votre application de recevoir des jetons. Assurez-vous que vos applications n’essaient pas d’acquérir un jeton avant l’expiration du délai dans le champ de réponse Nouvelle tentative après. L’erreur 429 indique généralement que l’application ne met pas en cache et ne réutilise pas de manière adéquate les jetons.

HTTP 5xx

Si une application reçoit un code d'erreur HTTP 5x, l’application ne doit pas entrer dans une boucle rapide de nouvelle tentative. Assurez-vous que les applications attendent l’expiration du champ Nouvelle tentative après. Si aucun en-tête « Nouvelle tentative après » n’est fourni par la réponse, utilisez une nouvelle tentative exponentielle d’interruption avec la première tentative au moins 5 secondes après la réponse.

Quand une requête expire, confirmez que les applications ne font pas de nouvelle tentative immédiatement. Utilisez la nouvelle tentative exponentielle d’interruption précédemment citée.

Étapes suivantes