Vue d’ensemble des autorisations Microsoft Graph
Avant que le Plateforme d'identités Microsoft puisse autoriser votre application à accéder aux données dans le cloud Microsoft, l’application doit disposer des privilèges dont elle a besoin. De même, avant que le Plateforme d'identités Microsoft puisse autoriser votre application à accéder aux données via Microsoft Graph, l’application doit disposer des privilèges dont elle a besoin.
L’une des façons d’accorder à une application les privilèges dont elle a besoin pour accéder à vos données et l’utiliser via Microsoft Graph consiste à lui attribuer des autorisations Microsoft Graph.
Cet article présente les autorisations Microsoft Graph et fournit des conseils pour les utiliser. Pour afficher la liste complète des autorisations exposées par Microsoft Graph, consultez la référence des autorisations Microsoft Graph.
Pour en savoir plus sur le fonctionnement des autorisations, watch 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 aux applications 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 des autorisations déléguées et des autorisationsd’application.
Autorisations déléguées
Les autorisations déléguées, également appelées étendues, sont utilisées dans le scénario d’accès délégué. Il s’agit d’autorisations qui permettent à l’application d’agir au nom d’un utilisateur connecté. Toutefois, l’application ne pourra jamais accéder à quelque chose que l’utilisateur connecté n’a pas pu accéder.
Par exemple, une application a reçu l’autorisation déléguée Files.Read.All pour le compte de Tom, un utilisateur. L’application ne peut lire que tous les fichiers du organization auxquels Tom peut déjà accéder. Tom peut être en mesure d’accéder aux fichiers, car il dispose d’autorisations de l’une des manières suivantes :
- Tom a créé ou possède les fichiers.
- Les fichiers ont été partagés directement avec Tom, ou indirectement partagés avec lui par le biais d’une équipe ou d’une appartenance à un groupe.
- Des autorisations ont été accordées à Tom via un système de contrôle d’accès en fonction du rôle (RBAC) tel que Microsoft Entra RBAC.
Par conséquent, dans un scénario délégué, les privilèges qu’une application a pour agir au nom d’un utilisateur sont déterminés par les autorisations Microsoft Graph accordées à l’application et les propres autorisations de l’utilisateur.
Dans un scénario d’accès délégué, une application peut autoriser les utilisateurs à se connecter avec leur compte Microsoft personnel, comme les comptes Outlook.com, professionnels ou scolaires, ou autoriser 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 des 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 peut donner son consentement aux autorisations déléguées, ou, dans certains cas, à un administrateur. S’ils accordent leur consentement, l’application peut accéder aux ressources et aux API dans les limites des autorisations de l’utilisateur.
Remarque
Les autorisations accordées via Microsoft Entra rôles intégrés ne limitent pas l’application à l’appel des API Microsoft Graph uniquement.
Autorisations de l’application
Les autorisations d’application, également appelées rôles d’application, sont utilisées dans le scénario d’accès d’application uniquement, sans utilisateur connecté. L’application sera 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 peut lire n’importe quel fichier dans le organization.
Pour les applications qui accèdent aux ressources et aux API sans utilisateur connecté, les autorisations d’application peuvent être accordées par un administrateur lorsque l’application est installée dans le locataire ou via le centre d'administration Microsoft Entra. Seul un administrateur peut donner son consentement aux autorisations d’application.
En plus de se voir attribuer des autorisations d’application Microsoft Graph, une application peut également se voir accorder les 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 l’application reçoit un Microsoft Entra rôles d’administration intégrés ou personnalisés.
Remarque
Les autorisations accordées via Microsoft Entra rôles intégrés ne limitent pas l’application à l’appel des API Microsoft Graph uniquement.
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 | Seul l’administrateur peut donner son consentement | |
| Autres noms | ||
| Résultat du consentement | oAuth2PermissionGrant | 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é ou d’application uniquement.
Modèle de nommage des 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 la messagerie. Ces autorisations sont nommées selon le modèle suivant :
{resource}. {operation}. {constraint}
| Valeur | Description | Exemples |
|---|---|---|
{resource} |
Fait référence à une ressource Microsoft Graph à laquelle l’autorisation autorise l’accès. Par exemple, la user ressource . |
User, Applicationou Group |
{operation} |
Fait référence aux opérations microsoft API Graph autorisées sur les données exposées par la ressource. Par exemple, Read pour les opérations de lecture seule ou ReadWrite pour les opérations de lecture, de création, de mise à jour et de suppression. |
Read, ReadBasic, ReadWrite, Create, Manage, ou Migrate |
{constraint} |
Détermine l’étendue potentielle de l’accès d’une application dans le répertoire. Cette valeur peut ne pas être déclarée explicitement. Lorsqu’elle n’est pas déclarée, la contrainte par défaut est limitée aux données détenues par 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 dans le 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 des 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.
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 disposant des privilèges appropriés interroge l’appartenance d’un objet conteneur, elle reçoit une 200 OK réponse et une collection d’objets. Toutefois, si l’application ne dispose pas des autorisations nécessaires pour lire un certain type d’objet dans le conteneur, les objets de ce type sont retournés, mais avec des informations limitées, par exemple, seuls le type d’objet et l’ID peuvent être retournés et d’autres propriétés sont indiquées comme null. Des informations complètes sont retournées pour les types d’objets que l’application a les autorisations de lecture.
Ce principe est appliqué à toutes les relations de type directoryObject . Voici des exemples :/groups/{id}/members, /users/{id}/memberOf ou me/ownedObjects.
Exemple de scénario
Les membres d’un groupe sont des utilisateurs, des groupes et des appareils. Une application a reçu les autorisations User.Read.All et Group.Read.All de Microsoft Graph. L’application appelle l’API list group members pour récupérer les membres du groupe.
Pour lire les propriétés de base des membres d’un groupe qui sont des utilisateurs, l’application a besoin au moins de l’autorisation User.Read.All . Pour lire les propriétés de base des membres d’un groupe qui sont des groupes, l’application a besoin au moins de l’autorisation Group.Read.All . Pour lire les propriétés de base des membres d’un groupe qui sont des appareils, l’application a besoin au moins de l’autorisation Device.Read.All .
Étant donné que l’application dispose des autorisations nécessaires pour accéder uniquement aux objets utilisateur et groupe dans le groupe, mais pas aux objets d’appareil, dans la réponse :
- Toutes les propriétés de base des objets utilisateur et membre du groupe sont retournées.
- Pour les objets membres de l’appareil, seuls le type d’objet et l’ID d’objet sont retournés, mais toutes les autres propriétés ont la valeur Null.
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 privilège minimum lors de l’attribution et de l’octroi d’autorisations à une application, en accordant à l’application l’autorisation minimale dont elle a besoin pour l’opération.
Prenons les exemples suivants :
- Une application doit uniquement 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 de l’autorisation User.ReadWrite à l’application la rend trop privilégiée, car l’application n’a pas besoin de mettre à jour le profil de l’utilisateur.
- Une application doit lire les groupes dans le locataire sans utilisateur connecté. L’application nécessite uniquement l’autorisation d’application Group.Read.All , qui est l’autorisation la moins privilégiée pour lire les groupes dans le locataire sans utilisateur connecté.
- Une application doit lire ou écrire dans un calendrier de l’utilisateur connecté. L’application gère les travaux dynamiques et se synchronise à partir du calendrier Outlook de l’utilisateur pour maintenir l’application à jour afin de planifier des travaux 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 travaux planifiés 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é qui expose une application à un accès non autorisé et involontaire aux données ou aux 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.
Appliquez le principe du privilège minimum 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 privilège minimum et Création d’applications qui sécurisent l’identité par le biais d’autorisations et de consentement.
Limites sur les autorisations demandées par application
Microsoft Entra ID limite le nombre d’autorisations qui peuvent être demandées et consenté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 |
Récupérer des ID d’autorisation via Microsoft Graph
Pour définir des autorisations à l’aide d’Azure CLI, de PowerShell ou d’infrastructures en tant que code, vous pouvez avoir 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 programmation 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 d’application, déléguées et spécifiques à la ressource.
Contenu connexe
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour