Augmenter la résilience de l’authentification et de l’autorisation dans les applications démon que vous développez
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.
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
- Augmenter la résilience de l’authentification et de l’autorisation dans les applications clientes que vous développez
- Renforcer la résilience de votre infrastructure de gestion des identités et des accès
- Renforcer la résilience de votre gestion des identités et des accès client avec Azure Active Directory B2C