Partager via

Vue d’ensemble des autorisations et du consentement dans la Plateforme d’identités Microsoft

Dans la plateforme d’identités Microsoft, la compréhension des autorisations et du consentement est essentielle pour le développement d’applications sécurisées qui nécessitent l’accès aux ressources protégées. Cet article fournit une vue d’ensemble des concepts fondamentaux et des scénarios liés aux autorisations et au consentement, ce qui aide les développeurs d’applications à demander les autorisations nécessaires aux utilisateurs et aux administrateurs. En comprenant ces concepts, vous pouvez vous assurer que vos applications demandent uniquement l’accès dont elles ont besoin, favorisant la confiance et la sécurité.

Pour accéder à une ressource protégée telle que les données de messagerie ou de calendrier, votre application a besoin de l’autorisation du propriétaire de la ressource. Le propriétaire de la ressource peut donner son consentement ou refuser la demande de votre application. La compréhension de ces concepts fondamentaux vous permet de créer des applications plus sécurisées et fiables qui demandent uniquement l’accès dont ils ont besoin, quand ils en ont besoin, des utilisateurs et des administrateurs.

Scénarios d’accès

En tant que développeur d’applications, vous devez identifier la façon dont votre application accède aux données. L’application peut utiliser un accès délégué pour le compte d’un utilisateur connecté, ou un accès « application uniquement » seulement comme l’identité propre de l’application.

Image montrant l’illustration des scénarios d’accès.

Accès délégué (accès pour le compte d’un utilisateur)

Dans ce scénario d’accès, un utilisateur s’est connecté à une application cliente. L’application cliente accède à la ressource pour le compte de l’utilisateur. L’accès délégué nécessite des autorisations déléguées. Le client et l’utilisateur doivent être autorisés séparément à effectuer la demande. Pour plus d’informations sur le scénario de l’accès délégué, consultez Scénario de l’accès délégué.

Pour l’application cliente, les autorisations déléguées correctes doivent être accordées. Les autorisations déléguées peuvent également être appelées « étendues ». Les étendues sont des autorisations pour une ressource donnée qui représentent ce à quoi une application cliente peut accéder pour le compte de l’utilisateur. Pour plus d’informations sur les étendues, consultez Étendues et autorisations.

Pour l’utilisateur, l’autorisation s’appuie sur les privilèges qui lui sont accordés pour lui permettre d'accéder à la ressource. Par exemple, l’utilisateur peut être autorisé à accéder à des ressources d’annuaire par le contrôle d’accès en fonction du rôle (RBAC) de Microsoft Entra, ou à des ressources de courrier et de calendrier par le contrôle RBAC d’Exchange Online. Pour plus d’informations sur RBAC pour les applications, consultez RBAC pour les applications.

Accès « application uniquement » (accès sans utilisateur)

Dans ce scénario d’accès, l’application agit seule sans utilisateur connecté. L’accès par l’application est utilisé dans des scénarios comme l’automatisation et la sauvegarde. Ce scénario inclut des applications qui s’exécutent en tant que services en arrière-plan ou en tant que démons. Il est approprié quand il n’est pas souhaitable d’avoir un utilisateur spécifique connecté ou quand les données nécessaires ne peuvent pas être délimitées à un seul utilisateur. Pour plus d’informations sur le scénario d’accès à l’application uniquement, consultez l’accès à l’application uniquement.

L’accès « application uniquement » utilise des rôles d’application au lieu d’étendues déléguées. Lorsqu’ils sont accordés par le biais du consentement, les rôles d’application peuvent également être appelés autorisations d’applications. L’application cliente doit disposer des autorisations d’application appropriées de la ressource d’application qu’elle appelle. Une fois les autorisations accordées, l’application cliente peut accéder aux données demandées. Pour plus d’informations sur l’attribution de rôles d’application aux applications clientes, consultez Attribution de rôles d’application aux applications.

Types d’autorisations

Les autorisations déléguées sont utilisées dans le scénario d’accès délégué. Ce sont des autorisations qui permettent à l’application d’agir au nom d’un utilisateur. L’application n’est pas en mesure d’accéder à quoi que ce soit que l’utilisateur connecté n’a pas pu accéder.

Par exemple, prenez une application qui reçoit l’autorisation Files.Read.All déléguée pour le compte de l’utilisateur. L’application est uniquement en mesure de lire des fichiers auxquels l’utilisateur peut accéder personnellement.

Les autorisations d’application, parfois appelées rôles d’application, sont utilisées dans le scénario de l’accès « application uniquement », sans qu’un utilisateur connecté soit présent. L’application est en mesure d’accéder aux données auxquelles l’autorisation est associée.

Par exemple, une application disposant de l’autorisation d’application Files.Read.All de l’API Microsoft Graph est en mesure de lire tout fichier du client via Microsoft Graph. En général, seul un administrateur ou propriétaire du principal de service d’une API peut consentir à des autorisations d’application exposées par cette API.

Comparatif entre les autorisations déléguées et les autorisations d’application

Types d’autorisations Autorisations déléguées Autorisations de l’application
Types d’applications Web / Mobile / application monopage (SPA) Web / Démon
Contexte d’accès Obtenir l’accès pour le compte d’un utilisateur Obtenir l’accès sans utilisateur
Qui peut donner son consentement - Les utilisateurs peuvent donner leur consentement pour leurs données
- Les administrateurs peuvent donner leur consentement pour tous les utilisateurs		 - Seul l’administrateur peut donner son consentement
Méthodes de consentement - Statique : liste configurée lors de l’inscription de l’application
- Dynamique : demander des autorisations individuelles lors de la connexion		 - Statique UNIQUEMENT : liste configurée lors de l’inscription de l’application
Autres noms - Étendues
- Étendues des autorisations OAuth2		 - Rôles d’application
- Autorisations « application uniquement »
Résultat du consentement (spécifique à Microsoft Graph) OAuth2PermissionGrant appRoleAssignment

Une des façons dont les applications reçoivent des autorisations est via un consentement. Le consentement est un processus où des utilisateurs ou des administrateurs autorisent une application à accéder à une ressource protégée. Par exemple, quand un utilisateur tente de se connecter à une application pour la première fois, l’application peut demander l’autorisation de voir le profil de l’utilisateur et de lire le contenu de la boîte aux lettres de l’utilisateur. L’utilisateur voit la liste des autorisations demandées par l’application via une invite de consentement. D’autres scénarios où les utilisateurs peuvent voir une invite de consentement sont les suivants :

  • Lorsque le consentement précédemment accordé est révoqué.
  • Lorsque l’application est codée précisément pour demander un consentement lors de la connexion.
  • Lorsque l’application utilise le consentement dynamique pour demander de nouvelles autorisations en fonction des besoins au moment de l’exécution.

Les informations importantes d’une invite de consentement sont la liste des autorisations demandées par l’application et les informations de l’éditeur. Pour plus d’informations sur l’invite de consentement et l’expérience de consentement pour les administrateurs et les utilisateurs finaux, consultez l’expérience de consentement de l’application.

Le consentement de l’utilisateur se produit quand un utilisateur tente de se connecter à une application. L’utilisateur fournit ses informations d’identification de connexion, qui sont vérifiées pour déterminer si le consentement est déjà accordé. S’il n’existe aucun enregistrement antérieur de consentement utilisateur ou administrateur pour les autorisations requises, l’utilisateur voit une invite de consentement qui lui demande d’accorder à l’application les autorisations nécessaires. Un administrateur peut être tenu d’accorder le consentement pour le compte de l’utilisateur.

Selon les autorisations dont ils ont besoin, certaines applications peuvent exiger qu’un administrateur donne son consentement. Par exemple, des autorisations d’application et de nombreuses autorisations déléguées à privilège élevé peuvent faire l’objet d’un consentement seulement par un administrateur.

Les administrateurs peuvent accorder leur consentement pour eux-mêmes ou pour l’ensemble de l’organisation. Pour en savoir plus sur le consentement utilisateur et administrateur, consultez Vue d’ensemble du consentement utilisateur et administrateur.

Des demandes d’authentification sont émises pour le consentement administrateur si le consentement n’a pas été accordé et si l’une de ces autorisations à privilèges élevés est demandée.

Les demandes d’autorisation comportant des étendues d’application personnalisées ne sont pas considérées comme des privilèges élevés et, par conséquent, elles ne nécessitent pas le consentement administrateur.

Pré-autorisation

La pré-authentification permet à un propriétaire d’application de ressource d’accorder des autorisations sans demander aux utilisateurs d’afficher une invite de consentement pour le même ensemble d’autorisations qui sont préautorisées. De cette façon, une application pré-autorisée ne demande pas aux utilisateurs de donner leur consentement aux autorisations. Les propriétaires de ressources peuvent préauthoriser des applications clientes dans le portail Azure ou à l’aide de PowerShell et d’API comme Microsoft Graph.

Dans la plupart des cas, les applications orientées client dans l’ID externe Microsoft Entra nécessitent toutes une préauthorisation, car elles sont destinées aux utilisateurs qui ne font pas partie de l’organisation et qui ne seraient pas en mesure de consentir aux autorisations demandées par l’application. La pré-authentification garantit que ces utilisateurs peuvent accéder à l’application sans être invités à donner leur consentement.

Autres systèmes d’autorisation

L’infrastructure de consentement est uniquement un moyen par lequel une application ou un utilisateur peut obtenir l’autorisation d’accéder à des ressources protégées. Les administrateurs doivent connaître d’autres systèmes d’autorisation qui peuvent accorder l’accès à des informations sensibles. Parmi les différents systèmes d’autorisation de Microsoft, citons les rôles intégrés Microsoft Entra, Azure RBAC, Exchange RBAC et le consentement spécifique aux ressources Teams.

Voir aussi

  • Last updated on