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

  • Article

Pour accéder à une ressource protégée comme les e-mails ou des données de calendrier, votre application a besoin de l’autorisation du propriétaire de la ressource. Le propriétaire de la ressource peut consentir à ou refuser la demande de votre application. Comprendre ces concepts fondamentaux vous aidera à créer des applications plus sécurisées et plus fiables, qui demandent seulement l’accès dont elles ont besoin et quand elles en ont besoin aux utilisateurs et 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 seule » 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 accordés à l’utilisateur pour 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) Microsoft Entra, ou à accéder à des ressources de messagerie et de calendrier par le contrôle RBAC Exchange Online. Pour plus d’informations sur RBAC pour les applications, consultez RBAC pour les applications.

Accès « application seule » (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 d’application uniquement, consultez Accès aux applications uniquement.

L’accès « application seule » utilise des rôles d’application au lieu d’étendues déléguées. Lorsqu’ils sont accordés par le biais d’un consentement, les rôles d’application peuvent également être appelés autorisations d’application. L’application cliente doit disposer des autorisations d’application appropriées de l’application de ressource 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 ne pourra jamais accéder à quoi que ce soit auquel l’utilisateur connecté lui-même n’a pas pu accéder.

Par exemple, supposons une application qui a reçu l’autorisation déléguée Files.Read.All pour le compte de l’utilisateur. L’application peut lire seulement les fichiers auxquels l’utilisateur peut accéder personnellement.

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

Par exemple, une application bénéficiant de l’autorisation d’application Files.Read.All de l’API Microsoft Graph peut lire n’importe quel fichier du locataire à l’aide de Microsoft Graph. En général, seul l’administrateur ou le 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 d’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 seule »
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. Voici d’autres scénarios où les utilisateurs peuvent voir une invite de consentement :

  • 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 Expérience de consentement d’une 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 a déjà été 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. Il peut être demandé à un administrateur d’accorder un 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ège élevé est demandée.

Les demandes d’autorisation qui contiennent 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é-autorisation permet à un propriétaire d’application de ressource d’accorder des autorisations sans que les utilisateurs voient une invite de consentement pour le même ensemble d’autorisations qui ont été pré-autorisées. De cette façon, une application qui a été pré-autorisée ne demande pas aux utilisateurs de donner leur consentement aux autorisations. Les propriétaires de ressource peuvent pré-autoriser des applications clientes dans le portail Azure, ou en utilisant PowerShell et des API, comme Microsoft Graph.

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 Entra, le RBAC d’Azure, RBAC d’Exchange et le consentement spécifique aux ressources de Teams.

Voir aussi