Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Pour que la plateforme d’identités Microsoft puisse autoriser votre application à accéder aux données dans le cloud Microsoft, vous devez accorder à l’application les privilèges dont elle a besoin. De même, pour que la Plateforme d’identités Microsoft puisse autoriser votre application à accéder aux données via Microsoft Graph, vous devez accorder à l’application les privilèges dont elle a besoin.
Une façon d’accorder à une application les privilèges dont elle a besoin pour accéder à vos données et les utiliser via Microsoft Graph consiste à lui attribuer des autorisations Microsoft Graph. Une autre solution consiste à utiliser des systèmes de contrôle d’accès en fonction du rôle (RBAC), comme Microsoft Entra RBAC. Dans certains cas, l’accès aux données via les API de Microsoft Graph peut nécessiter à la fois des autorisations Microsoft Graph et des autorisations RBAC.
Cet article présente les autorisations Microsoft Graph et fournit des instructions pour les utiliser. Pour afficher la liste complète des autorisations que Microsoft Graph expose, consultez la référence des autorisations Microsoft Graph.
Pour en savoir plus sur le fonctionnement des autorisations, regardez la vidéo suivante.
Types d’autorisation
Microsoft Graph prend en charge deux scénarios d’accès : l’accès délégué et l’accès à l’application uniquement. Dans l’accès délégué, l’application appelle Microsoft Graph au nom d’un utilisateur connecté. Dans l’accès à l’application uniquement, l’application appelle Microsoft Graph avec sa propre identité, sans utilisateur connecté.
Pour prendre en charge ces scénarios d’accès, Microsoft Graph expose les autorisations déléguées et les autorisations d’application.
Autorisations déléguées
Les autorisations déléguées, également appelées étendues, fonctionnent dans le scénario d’accès délégué. Ces autorisations permettent à l’application d’agir pour le compte d’un utilisateur connecté. Toutefois, l’application ne peut pas accéder à tout ce à quoi l’utilisateur connecté n’a pas pu accéder.
Par exemple, une application obtient le Files. Autorisations déléguées Read.All au nom de Tom, un utilisateur. L’application peut uniquement lire tous les fichiers de l’organisation auxquels Tom peut déjà accéder. Tom peut être en mesure d’accéder aux fichiers car il dispose d’autorisations via l’une des méthodes suivantes :
- Tom a créé ou possède les fichiers.
- Les fichiers ont été partagés directement avec Tom, ou indirectement via une appartenance à une équipe ou à un groupe.
- Tom a reçu des autorisations par le biais d’un système RBAC pris en charge.
Par conséquent, dans un scénario délégué, les privilèges dont dispose une application pour agir au nom d’un utilisateur sont déterminés par les autorisations Microsoft Graph accordées à l’application et par les propres autorisations de l’utilisateur.
Dans un scénario d’accès délégué, une application peut permettre aux utilisateurs de se connecter avec leurs comptes Microsoft personnels, tels que les comptes Outlook.com, professionnels ou scolaires, ou les deux types de comptes. Toutes les autorisations déléguées sont valides pour les comptes professionnels ou scolaires, mais pas toutes pour les comptes Microsoft personnels. Utilisez la référence d’autorisations Microsoft Graph pour identifier les autorisations déléguées qui sont valides pour les comptes Microsoft personnels.
Lorsqu’un utilisateur se connecte à une application, il ou, dans certains cas, un administrateur a la possibilité de consentir aux autorisations déléguées. S’ils accordent le consentement, l’application peut accéder aux ressources et aux API dans les limites des autorisations de l’utilisateur.
Remarque
Les autorisations accordées par le biais des rôles intégrés de Microsoft Entra ne limitent pas l’application à appeler uniquement des API Microsoft Graph.
Autorisations de l’application
Les autorisations d’application, également appelées rôles d’application, fonctionnent dans le scénario d’accès à l’application uniquement, sans la présence d’un utilisateur connecté. L’application peut accéder à toutes les données auxquelles l’autorisation est associée. Par exemple, une application a accordé les Files. L’autorisation d’application Read.All peut lire n’importe quel fichier de l’organisation.
Avec l’autorisation d’application User.ReadWrite.All , une application peut mettre à jour de nombreuses propriétés utilisateur accessibles en écriture prises en charge par Microsoft Graph, y compris pour les utilisateurs auxquels des rôles d’administrateur privilégiés sont attribués.
Les autorisations d’application sont hautement privilégiées, car elles permettent aux applications d’accéder aux ressources et de les modifier sans nécessiter d’utilisateur connecté. Du point de vue du moindre privilège, le modèle d’autorisation déléguée est l’approche recommandée chaque fois qu’il répond aux exigences de l’application.
Pour les applications qui accèdent aux ressources et aux API sans utilisateur connecté, un administrateur accepte les autorisations d’application lorsque l’application est installée dans le locataire ou via le centre d’administration Microsoft Entra. Seuls l’administrateur de rôle privilégié et l’administrateur général peuvent donner leur consentement aux autorisations d’application.
Outre l’attribution des autorisations d’application Microsoft Graph, une application peut également bénéficier des privilèges dont elle a besoin dans l’une des conditions suivantes :
- Lorsque l’application se voit attribuer la propriété de la ressource qu’elle a l’intention de gérer.
- Lorsque des autorisations sont attribuées à l’application par le biais d’un système RBAC ou de rôles d’administration personnalisés.
Remarque
Les autorisations accordées par le biais des rôles intégrés de Microsoft Entra ne limitent pas l’application à appeler uniquement des API Microsoft Graph.
Comparaison de l’autorisation déléguée et de l’autorisation d’application
| Catégorie | Autorisations déléguées | Autorisations de l’application |
|---|---|---|
| Types d’applications | Application web / Mobile / Application monopage (SPA) | Web / Daemon |
| Contexte d’accès | Obtenir l’accès au nom d’un utilisateur | Obtenir l’accès sans utilisateur |
| Qui peut consentir |
La disponibilité du consentement de l’utilisateur dépend également des stratégies de consentement de l’application de votre client. Même lorsque le consentement de l’administrateur n’est pas requis pour une autorisation par défaut, les stratégies de votre organisation peuvent toujours restreindre le consentement de l’utilisateur |
Seul l’administrateur peut donner son consentement |
| Autres noms | ||
| Résultat du consentement | Objet oAuth2PermissionGrant | objet appRoleAssignment |
| Types signInAudience pris en charge | AzureADMyOrg AzureADMultipleOrgs AzureADandPersonalMicrosoftAccount PersonalMicrosoftAccount |
AzureADMyOrg AzureADMultipleOrgs AzureADandPersonalMicrosoftAccount |
L’image suivante illustre les privilèges d’une application dans les scénarios d’accès délégué et d’accès à l’application uniquement.
Meilleures pratiques pour sélectionner les types d’autorisations pour l’inscription de l’agent de connecteur
Les agents du connecteur Microsoft Graph s’exécutent en tant que services d’arrière-plan et nécessitent des autorisations d’application Microsoft Graph.
Les autorisations déléguées ne sont pas prises en charge pour l’inscription de l’agent de connecteur et provoquent des échecs d’inscription, même lorsque les autorisations semblent correctement configurées.
Demandez les autorisations d’application les moins privilégiées nécessaires pour votre scénario de connecteur et assurez-vous que le consentement de l’administrateur à l’échelle du client est accordé.
Modèle d’attribution de noms d’autorisations
Microsoft Graph expose des autorisations granulaires qui vous aident à contrôler l’accès des applications aux ressources Microsoft Graph, telles que les utilisateurs, les groupes et le courrier. Ces autorisations suivent le modèle de nommage :
{ressource}. {opération}. {contrainte}
| Valeur | Description | Exemples |
|---|---|---|
{resource} |
Fait référence à une ressource Microsoft Graph à laquelle l’autorisation accorde l’accès. Par exemple, la user ressource. |
User, Applicationou Group |
{operation} |
Fait référence aux opérations de l’API Graph qui sont autorisées sur les données exposées par la ressource. Par exemple, Read pour les opérations de lecture uniquement, ou ReadWrite pour les opérations de lecture, de création, de mise à jour et de suppression. |
Read, , ReadBasicReadWrite, CreateManageouMigrate |
{constraint} |
Détermine l’étendue potentielle d’accès d’une application dans le répertoire. Cette valeur n’est peut-être pas déclarée explicitement. Lorsqu’elle n’est pas déclarée, la contrainte par défaut est limitée aux données appartenant à l’utilisateur connecté. |
All, AppFolder, OwnedBy, Selected, Shared, Hidden |
Exemples :
- User.Read : permet à l’application de lire des informations sur l’utilisateur connecté.
- Application.ReadWrite.All : permet à l’application de gérer toutes les applications du locataire.
- Application.ReadWrite.OwnedBy : permet à l’application de gérer uniquement les applications qu’elle crée ou possède.
- Group.Create : permet à l’application de créer de nouveaux groupes, mais pas de les modifier ou de les supprimer.
- Member.Read.Hidden : permet à l’application de lire les appartenances masquées.
Pour obtenir la liste complète des autorisations exposées par Microsoft Graph, consultez la référence des autorisations Microsoft Graph.
Autorisations de consentement spécifiques à la ressource (RSC)
RSC est une infrastructure d’autorisation qui accorde un accès étendu aux données exposées par une ressource. Par le biais de RSC, un utilisateur autorisé peut donner à une application l’accès aux données d’un instance spécifique d’un type de ressource. Ils n’ont pas besoin de donner l’accès de l’application à chaque instance du type de ressource dans l’ensemble du client.
Les autorisations RSC sont également disponibles pour le consentement et sont prises en charge uniquement par un sous-ensemble de fonctionnalités disponibles via Microsoft Graph, telles que Teams, les conversations et les messages. Pour plus d’informations, voir Autorisations RSC et la liste complète des autorisations RSC disponibles.
Informations limitées retournées pour les objets membres inaccessibles
Les objets conteneur tels que les groupes prennent en charge les membres de différents types, par exemple, les utilisateurs et les appareils. Lorsqu’une application avec les privilèges appropriés interroge l’appartenance à un objet conteneur, elle reçoit une réponse et une 200 OK collection d’objets. Toutefois, si l’application ne dispose pas des autorisations nécessaires pour lire un certain type d’objet dans le conteneur, elle reçoit des objets de ce type, mais avec des informations limitées. Par exemple, seuls le type et l’ID d’objet peuvent être renvoyés, et les autres propriétés sont indiquées comme null. L’application reçoit des informations complètes pour les types d’objets qu’elle est autorisée à lire.
Ce principe s’applique à toutes les relations de type directoryObject . Par exemple, /users/{id}/memberOf, , /groups/{id}/memberset me/ownedObjects.
Par exemple, un groupe peut avoir des utilisateurs, des groupes, des applications, des principaux de service, des appareils et des contacts en tant que membres. Une application reçoit l’autorisation les moins privilégiés GroupMember.Read.All pour lister les membres du groupe. Dans l’objet response, seules les propriétés id et @odata.type sont renseignées pour tous les membres renvoyés. Les autres propriétés sont indiquées sous la forme null. Pour cette API et pour retourner plus d’informations pour les membres du groupe, l’application a besoin des autorisations supplémentaires suivantes :
- Pour lire les propriétés de base des membres d’un groupe qui sont des utilisateurs, User.ReadBasic.All est l’autorisation de moindre privilège.
- Pour lire les propriétés de base des membres d’un groupe qui sont des groupes, GroupMember.Read.All est l’autorisation de moindre privilège.
- Pour lire les propriétés de base des membres d’un groupe qui sont des appareils, Device.Read.All est l’autorisation de moindre privilège.
- Pour lire les propriétés de base des membres d’un groupe qui sont des principaux de service, Application.Read.All est l’autorisation de moindre privilège.
- Conformément au principe du moindre privilège, utilisez les autorisations précédentes en fonction de votre application ; Toutefois, au lieu des autorisations individuelles au niveau des ressources, attribuez à l’application l’autorisation Directory.Read.All pour lire toutes les propriétés de tous les types de membres.
Exemple
Demande
GET https://graph.microsoft.com/v1.0/groups/{id}/members
Réponse
L’objet suivant est un exemple de réponse :
{
"@odata.context":"https://graph.microsoft.com/v1.0/$metadata#directoryObjects",
"value":[
{
"@odata.type":"#microsoft.graph.user",
"id":"69d035a3-29c9-469f-809d-d21a4ae69e65",
"displayName":"Adele Vance",
"createdDateTime":"2019-09-18T09:06:51Z",
},
{
"@odata.type":"#microsoft.graph.group",
"id":"c43a7cc9-2d95-44b6-bf6a-6392e41949b4",
"displayName":"All Company",
"description":null,
"createdDateTime":"2019-10-24T01:34:35Z"
},
{
"@odata.type":"#microsoft.graph.device",
"id": "d282309e-f91d-43b6-badb-9e68aa4b4fc8",
"accountEnabled":null,
"deviceId":null,
"displayName":null,
"operatingSystem":null,
"operatingSystemVersion":null
}
]
}
Meilleures pratiques pour l’utilisation des autorisations Microsoft Graph
Microsoft Graph expose des autorisations granulaires qui permettent à une application de demander uniquement les autorisations dont elle a besoin pour fonctionner. Les autorisations granulaires vous permettent d’appliquer le principe du moindre privilège lors de l’attribution et de l’octroi d’autorisations à une application. Accordez à l’application l’autorisation minimale dont elle a besoin pour l’opération.
Prenons les exemples suivants :
- Une application doit lire les informations de profil de l’utilisateur connecté. L’application nécessite uniquement l’autorisation User.Read , qui est l’autorisation la moins privilégiée pour accéder aux informations de l’utilisateur connecté. L’octroi à l’application de l’autorisation User.ReadWrite la rend surprivilégiée, car l’application n’a pas besoin de mettre à jour le profil de l’utilisateur.
- Une application doit lire les groupes du client sans utilisateur connecté. L’application nécessite uniquement l’autorisation d’application GroupMember.Read.All , qui est l’autorisation de moindre privilège pour lire les groupes du client sans utilisateur connecté.
- Une application doit lire ou écrire dans le calendrier de l’utilisateur connecté. L’application gère les tâches dynamiques et se synchronise à partir du calendrier Outlook de l’utilisateur pour maintenir l’application à jour afin de planifier les tâches pour l’utilisateur. Même si l’obtention des données de calendrier de l’utilisateur nécessite Calendars.Read, la mise à jour du calendrier avec des tâches planifiées nécessite une autorisation privilégiée plus élevée, Calendars.ReadWrite. Dans ce cas, l’application doit demander Calendars.ReadWrite.
Accorder à une application plus de privilèges qu’elle n’en a besoin est une mauvaise pratique de sécurité. Elle augmente l’exposition de l’application à des accès non autorisés et non intentionnels à des données ou à des opérations. En outre, demander plus d’autorisations que nécessaire peut amener les utilisateurs à s’abstenir de donner leur consentement à une application, ce qui affecte l’adoption et l’utilisation d’une application.
Appliquer le principe du moindre privilège lors de l’attribution et de l’octroi d’autorisations Microsoft Graph à une application. Pour plus d’informations, consultez Améliorer la sécurité avec le principe du moindre privilège et Créer des applications qui sécurisent l’identité par le biais d’autorisations et de consentement.
Autorisations à utiliser avec prudence
Certaines autorisations Microsoft Graph accordent l’accès à un plus large éventail de données ou d’opérations que d’autres. Utilisez ces autorisations avec prudence. Par exemple, l’autorisation Directory.AccessAsUser.All est l’autorisation déléguée privilégiée la plus élevée qui accorde l’accès à presque toutes les opérations d’API sur Microsoft Entra ID. L’autorisation Directory.ReadWrite.All est la deuxième dans le classement des privilèges. Directory.Read.All est l’autorisation de lecture seule au privilège le plus élevé pour les ressources Microsoft Entra ID. Utilisez ces autorisations avec prudence et uniquement lorsque cela est nécessaire. Utilisez toujours les autorisations des options moins privilégiées à la place.
Dans la documentation de référence de l’API relative aux ressources Microsoft Entra ID, certaines de ces autorisations privilégiées plus élevées peuvent être intentionnellement exclues du tableau des autorisations prises en charge pour accéder à l’API.
En outre, le rôle Administrateur général est le rôle intégré le plus privilégié dans Microsoft Entra ID. Dans la documentation de référence de l’API, ce rôle est intentionnellement exclu de la liste des rôles qui prennent en charge l’accès à l’API au profit de rôles moins privilégiés.
Limites sur les autorisations demandées par application
Microsoft Entra ID limite le nombre d’autorisations qui peuvent être demandées et acceptées par une application cliente. Ces limites dépendent de la signInAudience valeur d’une application, affichée dans le manifeste de l’application.
| signInAudience | Utilisateurs autorisés | Autorisations maximales que l’application peut demander | Autorisations maximales de Graph Microsoft que l’application peut demander | Autorisations maximales qui peuvent être consenties dans une seule demande |
|---|---|---|---|---|
| AzureADMyOrg | Les utilisateurs de l’organisation où l’application est inscrite | 400 | 400 | Environ 155 autorisations déléguées et environ 300 autorisations d’application |
| AzureADMultipleOrgs | Utilisateurs de n’importe quel Microsoft Entra organization | 400 | 400 | Environ 155 autorisations déléguées et environ 300 autorisations d’application |
| PersonalMicrosoftAccount | Utilisateurs consommateurs (tels que les comptes Outlook.com ou Live.com) | 30 | 30 | 30 |
| AzureADandPersonalMicrosoftAccount | Utilisateurs consommateurs et utilisateurs de n’importe quel Microsoft Entra organization | 30 | 30 | 30 |
Remarque
Pour l’Identifiant d’assistant Microsoft Entra, certaines autorisations Microsoft Graph à haut risque sont globalement bloquées pour les agents et ne peuvent pas être accordées aux identités d’agent.
Si vous incluez une étendue d’autorisation déléguée Microsoft Graph ou un rôle d’application bloqué dans la resourceAccess collection d’une requiredResourceAccess entrée, la demande est rejetée avec une réponse HTTP 400 Bad Request et une erreur indiquant que l’autorisation est bloquée et ne peut pas être accordée aux identités d’agent.
Pour obtenir la liste des autorisations Microsoft Graph bloquées pour les agents, consultez Autorisations Microsoft Graph bloquées pour les agents.
Récupérer les ID d’autorisation via Microsoft Graph
Pour définir des autorisations à l’aide des infrastructures Azure CLI, PowerShell ou Infrastructure as Code, vous aurez peut-être besoin de l’identificateur de l’autorisation que vous souhaitez utiliser au lieu du nom. La référence des autorisations répertorie les ID de toutes les autorisations Microsoft Graph. Vous pouvez également lire des informations sur toutes les autorisations Microsoft Graph par programme via l’API Get servicePrincipal dans Microsoft Graph. L’exemple suivant illustre une demande.
GET https://graph.microsoft.com/v1.0/servicePrincipals(appId='00000003-0000-0000-c000-000000000000')?$select=id,appId,displayName,appRoles,oauth2PermissionScopes,resourceSpecificApplicationPermissions
Les objets appRoles, oauth2PermissionScopes et resourceSpecificApplicationPermissions stockent respectivement les autorisations de consentement spécifiques à l’application, déléguées et spécifiques aux ressources.