Meilleures pratiques et recommandations relatives à la plateforme d’identité Microsoft

Cet article présente les bonnes pratiques, recommandations et les oublis courants lors de l’intégration à la plateforme d’identités Microsoft. Cette check-list vous guide pour réussir une intégration sécurisée et de haute qualité. Consultez cette liste régulièrement pour vous assurer de maintenir la qualité et la sécurité de l’intégration de votre application à la plateforme d’identité. La check-list n’est pas prévue pour passer en revue l’intégralité de votre application. Le contenu de la check-list est susceptible d’être modifié au fur et à mesure que nous apportons des améliorations à la plateforme.

Si vous venez juste de commencer, consultez la documentation de la plateforme d’identités Microsoft pour en savoir plus sur les principes fondamentaux de l’authentification, les scénarios d’application dans la plateforme d’identités Microsoft, et bien plus encore.

Utilisez la check-list suivante pour vous assurer que votre application est intégrée convenablement à la plateforme d’identités Microsoft.

Conseil

L’Assistant d’intégration peut vous aider à appliquer un grand nombre de ces meilleures pratiques et de ces suggestions. Sélectionnez l’une de vos inscriptions d’application, puis sélectionnez l’élément de menu Assistant d’intégration pour commencer à utiliser l’assistant.

Concepts de base

Lisez et comprenez les Stratégies de la plateforme Microsoft. Assurez-vous que votre application respecte les conditions décrites, car celles-ci sont conçues pour protéger les utilisateurs et la plateforme.

Propriété

Assurez-vous que les informations associées au compte utilisé pour vous inscrire et gérer des applications sont à jour.

Marque

Conformez-vous aux Directives de personnalisation des applications.

Fournissez un nom et un logo explicites pour votre application. Ces informations s’affichent dans l’invite de consentement de votre application. Assurez-vous que votre nom et le logo associé sont représentatifs de votre société/produit, afin que les utilisateurs puissent se décider en toute connaissance de cause. Assurez-vous que vous ne violez aucune marque commerciale.

Confidentialité

Fournissez les liens vers les conditions d’utilisation du service et la déclaration de confidentialité de votre application.

Sécurité

Gérer vos URI de redirection :

• Maintenez la propriété de tous vos URI de redirection et tenez à jour les enregistrements DNS connexes.
• N’utilisez pas les caractères génériques (*) dans vos URI.
• Pour les applications web, assurez-vous que tous les URI sont sécurisés et chiffrés (au moyen, par exemple, de schémas https).
• Pour les clients publics, utilisez les URI de redirection spécifiques à la plateforme, si nécessaire (principalement pour iOS et Android). Sinon, utilisez les URI de redirection avec une grande quantité de caractère aléatoire pour empêcher les collisions lors du rappel à votre application.
• Si votre application est utilisée à partir d’un agent web isolé, vous pouvez utiliser https://login.microsoftonline.com/common/oauth2/nativeclient.
• Passez en revue régulièrement tous les URI de redirection et supprimez ceux qui sont inutiles ou inutilisés.

Si votre application est inscrite dans un annuaire, réduisez et supervisez manuellement la liste des propriétaires d’inscription d’application.

N’activez pas la prise en charge du flux d’octroi implicite OAuth2, sauf si elle est explicitement demandée. Apprenez-en davantage sur le scénario valide ici.

Allez au-delà de la combinaison nom d’utilisateur/mot de passe. N’utilisez pas le flux d’informations d’identification du mot de passe du propriétaire de la ressource (ROPC), qui gère directement les mots de passe des utilisateurs. Ce flux nécessite un degré élevé de confiance et d’exposition des utilisateurs ; il devrait être utilisé seulement lorsqu’il est impossible d’utiliser d’autres flux plus sécurisés. Ce flux reste nécessaire dans certains scénarios (comme DevOps), mais il faut savoir que son utilisation peut imposer des contraintes à votre application. Pour approches plus modernes, consultez Flux d’authentification et scénarios d’applications.

Protégez et gérez vos informations d’identification d’application confidentielles pour les applications web, les API web et les applications de démon. Utilisez les informations d’identification du certificat, et non pas celles du mot de passe (clés secrètes clientes). Si vous devez utiliser une information d’identification de mot de passe, ne la définissez pas manuellement. Ne stockez pas les informations d’identification dans le code ou la configuration, et n’autorisez jamais leur gestion par des personnes. Si possible, utilisez les identités managées des ressources Azure ou Azure Key Vault pour stocker et faire tourner régulièrement vos informations d’identification.

Assurez-vous que votre application demande des autorisations avec des privilèges minimum. Demandez uniquement les autorisations dont votre application a absolument besoin, et seulement lorsque vous en avez besoin. Connaissez les différents types d’autorisations. Utilisez uniquement les autorisations d’application si nécessaire ; servez-vous des autorisations déléguées lorsque cela est possible. Pour obtenir la liste complète des autorisations Microsoft Graph, consultez Informations de référence sur les autorisations.

Si vous sécurisez une API à l’aide de la plateforme des identités Microsoft, réfléchissez longuement aux autorisations qui devront être exposées. Déterminez le bon niveau de granularité pour votre solution, et la ou les autorisations nécessitant le consentement de l’administrateur. Vérifiez les autorisations attendues dans les jetons entrants avant de prendre une décision en matière d’autorisation.

Implémentation

Utilisez des solutions d’authentification moderne (OAuth 2.0, OpenID Connect) pour connecter les utilisateurs en toute sécurité.

Ne programmez pas directement pour des protocoles comme OAuth 2.0 et Open ID. Au lieu de cela, tirez parti de Microsoft Authentication Library (MSAL). Les bibliothèques MSAL encapsulent de façon sûre les protocoles de sécurité dans une bibliothèque facile à utiliser, et vous bénéficiez d’une prise en charge intégrée des scénarios d’accès conditionnel, de l'authentification unique à l’échelle de l’appareil et de la mise en cache des jetons. Pour plus d’informations, consultez la liste des bibliothèques de client prises en charge par Microsoft. Si vous devez coder manuellement les protocoles d’authentification, vous devez suivre la méthodologie de développement de Microsoft Security Development Lifecycle ou une méthodologie similaire. Prêtez une attention toute particulière aux considérations de sécurité dans les spécifications de normes pour chaque protocole.

NE REGARDEZ PAS la valeur des jetons d’accès et n’essayez pas de l’analyser comme client. Les jetons d’accès peuvent changer de valeur, de format ou même être chiffrés sans préavis. Utilisez toujours l’ID du jeton si votre client souhaite en savoir plus sur l’utilisateur. Seules les API web doivent analyser les jetons d’accès (puisque ce sont elles qui définissent le format et les clés de chiffrement). L’envoi d’un jeton d’accès directement à une API par le client est un risque de sécurité, car il s’agit d’informations d’identification sensibles qui accordent l’accès à certaines ressources. Les développeurs ne doivent pas supposer que le client peut être approuvé pour valider le jeton d’accès.

Migrez des applications existantes de la Bibliothèque d'authentification Active Directory (ADAL) vers Microsoft Authentication Library. MSAL est la solution de plateforme d’identités de Microsoft la plus récente et elle est disponible sur .NET, JavaScript, Android, iOS, macOS, Python et Java. En savoir plus sur la migration d’applications ADAL.NET, ADAL.js et ADAL.NET et répartiteur iOS.

Pour les applications mobiles, configurez chaque plateforme à l’aide de l’expérience d’inscription d’application. Pour que votre application puisse tirer parti de Microsoft Authenticator ou du Portail d’entreprise Microsoft pour l’authentification unique, votre application a besoin d’un « URI de redirection de répartiteur » configuré. Cela permet à Microsoft de rendre le contrôle à votre application après l’authentification. Lors de la configuration de chaque plateforme, l’expérience d’inscription de l’application vous guide tout au long du processus. Utilisez le démarrage rapide pour télécharger un exemple fonctionnel. Sur iOS, utilisez les répartiteurs et la webview système dans la mesure du possible.

Dans les applications web et les API web, conservez un cache de jeton par compte. Pour les applications web, le cache de jeton doit être indexé par ID de compte. Pour les API web, le compte doit être indexé avec le hachage du jeton utilisé pour appeler l’API. MSAL.NET fournit une sérialisation personnalisée du cache de jeton dans .NET et .NET Framework. Pour des raisons de sécurité et de performances, nous vous recommandons de sérialiser un cache par utilisateur. Pour plus d’informations, consultez Sérialisation du cache de jeton.

Si les données exigées par votre application sont disponibles par le biais de Microsoft Graph, demandez les autorisations pour ces données avec le point de terminaison Microsoft Graph, plutôt qu’avec l’API individuelle.

Expérience de l’utilisateur final

Comprenez l’expérience de consentement et configurez les éléments de l’invite de consentement de votre application, afin que les utilisateurs finals et les administrateurs aient suffisamment d’informations pour déterminer s’ils font confiance à votre application.

Réduisez le nombre de fois où un utilisateur doit entrer des informations d’identification de connexion lorsqu’il utilise votre application ; essayez pour cela l’authentification silencieuse (acquisition de jeton en mode silencieux) avant les flux interactifs.

N’utilisez pas « prompt=consent » pour chaque connexion. Utilisez uniquement prompt=consent si vous avez déterminé que vous deviez demander le consentement pour des autorisations supplémentaires (par exemple, si vous avez modifié les autorisations exigées de votre application).

Le cas échéant, enrichissez votre application avec des données utilisateur. L’utilisation de l’API Microsoft Graph est un moyen simple de le faire. L’outil Afficheur Graph peut vous aider à démarrer.

Inscrivez le jeu complet d’autorisations dont votre application a besoin, afin que les administrateurs puissent donner leur consentement facilement à leur locataire. Utilisez le consentement incrémentiel au moment de l’exécution pour aider les utilisateurs à comprendre pourquoi votre application demande des autorisations qui, sinon, peuvent inquiéter ou désorienter les utilisateurs lorsqu’elles sont demandées au premier démarrage.

Implémentez une expérience de déconnexion unique normale. Il s’agit d’une exigence de sécurité et de confidentialité qui contribue à une bonne expérience utilisateur.

Test

Testez les Stratégies d’accès conditionnel qui peuvent avoir une incidence sur la capacité de vos utilisateurs à utiliser votre application.

Testez votre application avec tous les comptes possibles que vous prévoyez de prendre en charge (par exemple, les comptes professionnels ou scolaires, les comptes Microsoft personnels, les comptes enfants et les comptes souverains).

Ressources supplémentaires

Informations approfondies sur v2.0 :

• Plateforme d’identités Microsoft (présentation)
• Informations de référence sur les protocoles de la plateforme d’identités Microsoft
• Référence sur les jetons d’accès
• Référence sur les jetons d’ID
• Informations de référence sur les bibliothèques d’authentification
• Autorisations et consentement dans la plateforme d’identités Microsoft
• API Microsoft Graph