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, utilisez des autorisations déléguées. Si, toutefois, votre application s’exécute sans utilisateur connecté, par exemple un service en arrière-plan ou un démon, utilisez 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. Pour demander des autorisations ou des étendues, vous pouvez suivre ces modèles.

  • 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 autorisations. À mesure que l’utilisateur passe à différentes fonctionnalités dans votre application, vous demandez plus de consentement. 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, si votre application demande l’accès OneDrive, cela peut susciter des soupçons si vous demandez également l’accès 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 telles que Microsoft Graph vous permet de créer des applications enrichies, votre organisation ou votre client évalue les autorisations que votre application demande, ainsi que la fiabilité de votre application.

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 coche bleue s’affiche en regard du nom du serveur de publication (composant #5 dans l’exemple d’invite de consentement demandées ci-dessous . Référencez 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