Présentation des autorisations et du consentement

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 ils ont besoin, quand elles en ont besoin, à ses utilisateurs et ses 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) d’Azure Active Directory (Azure AD), ou à accéder à 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 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.

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. Pour l’accès « application seule », l’application cliente doit se voir attribuer les rôles d’application appropriés de l’application de ressources qu’elle appelle afin d’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, imaginez une application qui a reçu l’autorisation déléguée Files.Read.All pour le compte de Tom, l’utilisateur. L’application pourra lire seulement les fichiers auxquels Tom 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 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 à laquelle l’autorisation Files.Read.All est accordée peut lire n’importe quel fichier dans le locataire. Seul un administrateur ou un propriétaire du principal de service peut donner son consentement aux autorisations d’application.

Il existe d’autres façons d’accorder aux applications une autorisation d’accès « application seule ». Par exemple, un rôle RBAC Azure AD peut être octroyé à une application.

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

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
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 à chaque connexion.
  • Lorsque l’application utilise un consentement incrémentiel ou dynamique pour demander des autorisations à l’avance et d’autres autorisations plus tard si nécessaire.

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. Ces informations d’identification 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. Dans de nombreux cas, 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.

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.

Étapes suivantes