Partager via


Bonnes pratiques d’autorisation

À mesure que vous apprenez à développer des applications en suivant les principes de la Confiance Zéro, cet article s’appuie sur Acquérir l’autorisation d’accéder aux ressources, Développer une stratégie de permissions déléguées et Développer une stratégie d’autorisations d’application pour aller plus loin. Il vous aide, en tant que développeur, à implémenter les meilleurs modèles d’autorisation, de permission et de consentement pour vos applications.

Vous pouvez implémenter une logique d'autorisation dans les applications ou les solutions qui nécessitent un contrôle d'accès. Lorsque les approches d’autorisation s’appuient sur des informations sur une entité authentifiée, une application peut évaluer les informations échangées pendant l’authentification (par exemple, les informations fournies dans un jeton de sécurité). Lorsqu’un jeton de sécurité ne contient pas d’informations, une application peut effectuer des appels à des ressources externes.

Vous n’avez pas besoin d’incorporer entièrement la logique d’autorisation dans votre application. Vous pouvez utiliser des services d’autorisation dédiés peuvent être utilisés pour centraliser l’implémentation et la gestion des autorisations.

Meilleures pratiques pour les autorisations

Les applications les plus largement adoptées dans Microsoft Entra ID suivent les meilleures pratiques de consentement et d’autorisation. Passez en revue les meilleures pratiques pour utiliser les informations de référence sur les autorisations Microsoft Graph et Microsoft Graph pour savoir comment être réfléchie avec vos demandes d’autorisation.

  • Appliquez les privilèges minimum. Demandez uniquement les autorisations nécessaires. Utilisez le consentement incrémentiel pour demander des autorisations granulaires juste à temps. Limitez l'accès utilisateur avec l'accès juste-à-temps et juste suffisant (JIT/JEA), des stratégies adaptatives basées sur les risques et une protection des données.

  • Utilisez le type d’autorisation correct en fonction des scénarios. Évitez d’utiliser les permissions déléguées et d’application dans la même application. Si vous créez une application interactive où un utilisateur connecté est présent, votre application doit utiliser des permissions déléguées. Toutefois, si votre application s’exécute sans utilisateur connecté, comme un service ou démon en arrière-plan, votre application doit utiliser des autorisations d’application.

  • Fournir des conditions d’utilisation du service et des déclarations de confidentialité. L’expérience de consentement de l’utilisateur expose vos conditions d’utilisation et votre déclaration de confidentialité aux utilisateurs pour les aider à savoir qu’ils peuvent approuver votre application. Ils sont particulièrement importants pour les applications multilocataires accessibles aux utilisateurs.

Quand demander une autorisation

Certaines autorisations nécessitent l'intervention d'un administrateur pour être accordées au sein d'un client. Vous pouvez également utiliser le point de terminaison de consentement administrateur pour les autorisations accordées à un client entier. Il existe trois modèles que vous pouvez suivre pour demander des autorisations ou des étendues.

  • Implémentez le consentement de l’utilisateur dynamique lors de la connexion ou de la première demande de jeton d’accès. Le consentement de l’utilisateur dynamique ne nécessite rien dans l’inscription de votre application. Vous pouvez définir les étendues dont vous avez besoin dans certaines conditions (par exemple, lorsque vous vous connectez à un utilisateur pour la première fois). Après avoir demandé cette autorisation et reçu le consentement, vous n’aurez pas besoin de demander l’autorisation. Toutefois, si vous ne recevez pas le consentement de l’utilisateur dynamique au moment de la connexion ou du premier accès, l’expérience de permission est déclenchée.

  • Demandez le consentement de l’utilisateur incrémentiel en fonction des besoins. Avec le consentement incrémentiel combiné avec le consentement de l’utilisateur dynamique, vous n’avez pas besoin de demander toutes les autorisations à la fois. Vous pouvez demander quelques permissions, puis, à mesure que l’utilisateur accède à différentes fonctionnalités de votre application, demander un consentement plus important. Cette approche peut augmenter le niveau de confort de l’utilisateur au fur et à mesure qu’il accorde des autorisations de manière incrémentielle à votre application. Par exemple, une application qui demande l’accès à OneDrive peut éveiller des soupçons si vous demandez également l’accès au Calendrier. Au lieu de cela, demandez à l’utilisateur d’ajouter des rappels de calendrier sur son OneDrive.

  • Utiliser l’étendue /.default. L’étendue /.default imite efficacement l’ancienne expérience par défaut qui a examiné ce que vous avez placé dans l’inscription de l’application, compris les consentements dont vous avez besoin, puis demandé tous les consentements non encore accordés. Il ne vous oblige pas à inclure les autorisations dont vous avez besoin dans votre code, car elles se trouvent dans votre inscription d’application.

Devenir éditeur vérifié

Les clients Microsoft décrivent parfois des difficultés à décider quand autoriser une application à accéder au Plateforme d'identités Microsoft en vous connectant à un utilisateur ou en appelant une API. Tout en adoptant Confiance Zéro principes, ils veulent :

  • Visibilité et contrôle accrus.
  • Décisions réactives plus proactives et plus faciles.
  • Systèmes qui conservent la sécurité des données et réduisent la charge de décision.
  • Adoption accélérée de l’application pour les développeurs dignes de confiance.
  • Consentement restreint aux applications disposant d’autorisations à faible risque vérifiées par l’éditeur.

Bien que l’accès aux données dans des API comme Microsoft Graph vous permette de créer des applications riches, votre organisation ou votre client évalue les autorisations demandées par votre application ainsi que sa fiabilité.

Devenir un serveur de publication vérifié Microsoft vous aide à donner à vos clients une expérience plus facile d’accepter vos demandes d’application. Lorsqu’une application provient d’un éditeur vérifié, d’utilisateurs, de professionnels de l’informatique et de clients sait qu’elle provient d’une personne avec laquelle Microsoft a une relation commerciale. Une case activée mark bleue apparaît en regard du nom de l’éditeur (composant n° 5 dans l’exemple d’invite de consentement demandées des autorisations ci-dessous ; consultez la table des composants dans l’expérience de consentement de l’application Microsoft Entra). L’utilisateur peut sélectionner l’éditeur vérifié à partir de l’invite de consentement pour afficher plus d’informations.

La capture d’écran de la boîte de dialogue Autorisations demandées montre les éléments constitutifs décrits dans l’article sur le consentement à l’utilisation de l’application Microsoft Entra.

Lorsque vous êtes un éditeur vérifié, les utilisateurs et les professionnels de l’informatique gagnent en confiance dans votre application, car vous êtes une entité vérifiée. La vérification de l’éditeur fournit une personnalisation améliorée pour votre application et une transparence accrue, un risque réduit et une adoption plus fluide de l’entreprise pour vos clients.

Étapes suivantes