Partager via

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

Apprenez à renforcer la résilience dans les applications clientes qui utilisent la plateforme d’identités Microsoft et l’ID Microsoft Entra pour connecter des utilisateurs et effectuer des actions pour le compte de ces utilisateurs.

Utiliser la bibliothèque d’authentification Microsoft (MSAL)

La bibliothèque d’authentification Microsoft (MSAL) fait partie de la plateforme d’identités Microsoft. MSAL acquiert, gère, met en cache et actualise les jetons ; il utilise les meilleures pratiques pour la résilience. MSAL aide les développeurs à créer des solutions sécurisées.

Pour en savoir plus:

MSAL met en cache les jetons et utilise un modèle d’acquisition de jeton silencieux. MSAL sérialise le cache de jetons sur les systèmes d’exploitation qui fournissent en mode natif un stockage sécurisé comme la plateforme Windows universelle (UWP), iOS et Android. Personnalisez le comportement de sérialisation lorsque vous utilisez :

  • Microsoft.Identity.Web
  • MSAL.NET
  • MSAL pour Java
  • MSAL pour Python

Pour en savoir plus:

Lorsque vous utilisez MSAL, la mise en cache des jetons, l’actualisation et l’acquisition en mode silencieux sont prises en charge. Utilisez des modèles simples pour acquérir les jetons pour l’authentification. Il existe une prise en charge de nombreuses langues. Recherchez l’exemple de code sur les exemples de code de la plateforme d’identités Microsoft.

try
{
    result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
    result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}

MSAL peut actualiser les jetons. Lorsque la plateforme d’identités Microsoft émet un jeton de longue durée, elle peut envoyer des informations au client pour actualiser le jeton (refresh_in). L’application s’exécute pendant que l’ancien jeton est valide, mais il prend plus de temps pour une autre acquisition de jeton.

Versions MSAL

Nous recommandons aux développeurs de créer un processus pour utiliser la dernière version MSAL, car l’authentification fait partie de la sécurité des applications. Utilisez cette pratique pour les bibliothèques en cours de développement et améliorez la résilience des applications.

Trouvez la dernière version et les notes de version :

Modèles résilients pour la gestion des jetons

Si vous n’utilisez pas MSAL, utilisez des modèles résilients pour la gestion des jetons. La bibliothèque MSAL implémente les meilleures pratiques.

En règle générale, les applications utilisant l’authentification moderne appellent un point de terminaison pour récupérer des jetons qui authentifient l’utilisateur ou autorisent l’application à appeler des API protégées. MSAL gère l’authentification et implémente des modèles pour améliorer la résilience. Si vous n’utilisez pas MSAL, suivez les instructions de cette section pour connaître les meilleures pratiques. Sinon, MSAL implémente automatiquement les meilleures pratiques.

Le système d’authentification de sauvegarde microsoft Entra ID offre une résilience aux applications qui utilisent des protocoles et des flux pris en charge. Pour plus d’informations sur les exigences de l’application pour tirer parti de l’authentification de sauvegarde, consultez la configuration requise pour l’application pour le système d’authentification de sauvegarde.

Mettre en cache des jetons

Assurez-vous que les jetons de cache des applications proviennent exactement de la plateforme d’identités Microsoft. Une fois que votre application reçoit des jetons, la réponse HTTP avec des jetons a une expires_in propriété qui indique la durée à mettre en cache et quand la réutiliser. Confirmez que l’application ne tente pas de décoder un jeton d’accès d’API.

Diagramme d’une application appelant la plateforme d’identités Microsoft, via un cache de jetons sur l’appareil exécutant l’application.

Les jetons mis en cache empêchent le trafic inutile entre une application et la plateforme d’identités Microsoft. Ce scénario rend l’application moins vulnérable aux échecs d’acquisition de jetons en réduisant les appels d’acquisition de jetons. Les jetons mis en cache améliorent les performances de l’application, car l’application bloque l’acquisition de jetons moins fréquemment. Les utilisateurs restent connectés à votre application pour la durée de vie du jeton.

Sérialiser et conserver les jetons

Assurez-vous que les applications sérialisent leur cache de jetons en toute sécurité pour conserver les jetons entre les instances d’application. Réutilisez les jetons pendant leur durée de vie. Les jetons d’actualisation et les jetons d’accès sont émis pendant de nombreuses heures. Pendant ce temps, les utilisateurs peuvent démarrer votre application plusieurs fois. Quand une application démarre, confirmez qu’elle recherche un accès valide ou un jeton d’actualisation. Cela augmente la résilience et les performances des applications.

Pour en savoir plus:

Vérifiez que le stockage de jetons persistants dispose d’un contrôle d’accès et d’un chiffrement, par rapport à l’identité de l’utilisateur ou du processus. Sur différents systèmes d’exploitation, il existe des fonctionnalités de stockage d’informations d’identification.

Acquérir des jetons en mode silencieux

L’authentification d’un utilisateur ou la récupération de l’autorisation d’appeler une API implique plusieurs étapes dans la plateforme d’identités Microsoft. Par exemple, les utilisateurs qui se connectent pour la première fois entrent des informations d’identification et effectuent une authentification multifacteur. Chaque étape affecte la ressource qui fournit le service. La meilleure expérience utilisateur avec le moins de dépendances possible est l’acquisition de jetons silencieuse.

Diagramme des services de plateforme d’identités Microsoft qui permettent d’effectuer l’authentification ou l’autorisation des utilisateurs.

L’acquisition de jetons silencieux commence par un jeton valide à partir du cache de jetons d’application. S’il n’existe aucun jeton valide, l’application tente d’acquérir un jeton à l’aide d’un jeton d’actualisation disponible et du point de terminaison du jeton. Si aucune option n’est disponible, l’application acquiert un jeton à l’aide du prompt=none paramètre. Cette action utilise le point de terminaison d’autorisation, mais aucune interface utilisateur n’apparaît pour l’utilisateur. Si possible, la plateforme d’identités Microsoft fournit un jeton à l’application sans interaction utilisateur. Si aucune méthode n’entraîne de jeton, l’utilisateur se réauthentifie manuellement.

Remarque

En général, assurez-vous que les applications n’utilisent pas d’invites telles que « login » et « consent ». Ces invites forcent l’interaction de l’utilisateur, quand aucune interaction n’est requise.

Gestion du code de réponse

Utilisez les sections suivantes pour en savoir plus sur les codes de réponse.

Code de réponse HTTP 429

Il existe des réponses d’erreur qui affectent la résilience. Si votre application reçoit un code de réponse HTTP 429, trop de requêtes, la plateforme d’identités Microsoft limite vos demandes. Si une application effectue trop de requêtes, elle est restreinte pour empêcher l'application de recevoir des jetons. N’autorisez pas une application à tenter l’acquisition de jetons avant que le temps du champ de réponse Retry-After soit écoulé. Souvent, une réponse 429 indique que l’application ne met pas en cache et réutilise correctement les jetons. Vérifiez comment les jetons sont mis en cache et réutilisés dans l’application.

Code de réponse HTTP 5x

Si une application reçoit un code de réponse HTTP 5x, l’application ne doit pas entrer une boucle de nouvelle tentative rapide. Utilisez le même traitement pour une réponse 429. Si l’en-tête « Nouvelle tentative après » n’apparaît, mettez en œuvre une nouvelle tentative exponentielle d’interruption avec la première tentative au moins 5 secondes après la réponse.

Lorsqu’une demande expire, les nouvelles tentatives immédiates sont déconseillées. Implémentez une nouvelle tentative d’interruption exponentielle, avec la première nouvelle tentative, au moins 5 secondes après la réponse.

De nombreuses applications et API ont besoin d’informations utilisateur pour autoriser. Les méthodes disponibles présentent des avantages et des inconvénients.

Jetons

Les jetons d’identité (ID) et les jetons d’accès ont des revendications standard qui fournissent des informations. Si les informations nécessaires se trouvent dans le jeton, la technique la plus efficace est les revendications de jeton, car cela empêche un autre appel réseau. Moins d’appels réseau équivaut à une meilleure résilience.

Pour en savoir plus:

Remarque

Certaines applications appellent le point de terminaison UserInfo pour récupérer les revendications relatives à l’utilisateur authentifié. Les informations contenues dans le jeton d’ID sont un super-ensemble d’informations du point de terminaison UserInfo. Permettre aux applications d’utiliser le jeton d’ID au lieu d’appeler le point de terminaison UserInfo.

Augmentez les revendications standard de jetons avec des revendications optionnelles, telles que les groupes. L’option Groupe d’applications inclut les groupes affectés à l’application. Les options Tout or Groupes de sécurité incluent les groupes d’applications du même client, qui peuvent ajouter des groupes au jeton. Évaluez l’effet, car cela peut annuler l’efficacité de la demande de groupes dans le jeton en provoquant un surdimensionnement du jeton et en exigeant plus d’appels pour récupérer les groupes.

Pour en savoir plus:

Nous vous recommandons d’utiliser et d’inclure des rôles d’application, que les clients gèrent à l’aide du portail ou des API. Attribuez des rôles aux utilisateurs et aux groupes pour contrôler l’accès. Lorsqu’un jeton est émis, les rôles attribués se trouvent dans la déclaration des rôles du jeton. Les informations dérivées d’un jeton empêchent d’autres appels d’API.

Consultez, Ajouter des rôles d’application dans votre application et les recevoir dans le jeton

Ajoutez des revendications basées sur les informations du locataire. Par exemple, une extension a un ID utilisateur spécifique à l’entreprise.

L’ajout d’informations du répertoire à un jeton est efficace et augmente la résilience en réduisant les dépendances. Elle ne traite pas des problèmes de résilience en raison d’une incapacité à acquérir un jeton. Ajoutez des revendications facultatives pour les scénarios principaux de l’application. Si l’application requiert des informations pour les fonctionnalités d’administration, l’application peut obtenir ces informations, le cas échéant.

Microsoft Graph

Microsoft Graph dispose d’un point de terminaison d’API unifié pour accéder aux données Microsoft 365 sur les modèles de productivité, l’identité et la sécurité. Les applications utilisant Microsoft Graph peuvent utiliser des informations Microsoft 365 pour l’autorisation.

Les applications nécessitent un jeton pour accéder à Microsoft 365, ce qui est plus résilient que les API précédentes pour les composants Microsoft 365 tels que Microsoft Exchange ou Microsoft SharePoint nécessitant plusieurs jetons.

Lorsque vous utilisez des API Microsoft Graph, utilisez un Kit de développement logiciel (SDK) Microsoft Graph qui simplifie la création d’applications résilientes qui accèdent à Microsoft Graph.

Voir la vue d’ensemble du Kit de développement logiciel (SDK) Microsoft Graph

Pour l’autorisation, envisagez d’utiliser des revendications de jeton au lieu de certains appels Microsoft Graph. Demander des groupes, des rôles d’application et des revendications facultatives dans les jetons. Microsoft Graph pour l’autorisation nécessite plus d’appels réseau qui s’appuient sur le plateforme d’identités Microsoft et Microsoft Graph. Toutefois, si votre application s’appuie sur Microsoft Graph comme couche de données, Microsoft Graph pour l’autorisation n’est pas plus risqué.

Utiliser l’authentification broker sur les appareils mobiles

Sur les appareils mobiles, un répartiteur d’authentification comme Microsoft Authenticator améliore la résilience. Le courtier d’authentification utilise un jeton d’actualisation principal (PRT) avec des informations relatives à l’utilisateur et à l’appareil. Utilisez PRT pour les jetons d’authentification pour accéder à d’autres applications à partir de l’appareil. Lorsqu’un PRT demande l’accès aux applications, Microsoft Entra ID approuve son appareil et ses revendications MFA. Cela augmente la résilience en réduisant les étapes d’authentification de l’appareil. Les utilisateurs ne sont pas confrontés à plusieurs invites MFA sur le même appareil.

Voir, Qu’est-ce qu’un jeton d’actualisation principal ?

Diagramme d’une application appelant la plateforme d’identités Microsoft, via un cache de jetons et un magasin de jetons et un répartiteur d’authentification sur l’appareil exécutant l’application.

MSAL prend en charge l’authentification broker. Pour en savoir plus:

Évaluation continue de l’accès

L’évaluation continue de l’accès (CAE) augmente la sécurité et la résilience des applications avec des jetons de longue durée. Avec CAE, un jeton d’accès est révoqué en fonction des événements critiques et de l’évaluation de la stratégie, plutôt que des durées de vie de jeton courtes. Pour certaines API de ressources, étant donné que les risques et la stratégie sont évalués en temps réel, caE augmente la durée de vie des jetons jusqu’à 28 heures. MSAL actualise les jetons de longue durée.

Pour en savoir plus:

Si vous développez des API de ressources, accédez à openid.net pour Shared Signals – A Secure Webhooks Framework.

Étapes suivantes

  • Last updated on