Partager via

Vue d’ensemble des autorisations Microsoft Graph

  • Article

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. Une autre méthode 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 Microsoft Graph peut nécessiter des autorisations Microsoft Graph et des autorisations RBAC.

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 peut pas accéder à tout ce 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 peut uniquement lire 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 par le biais d’une appartenance à une équipe ou à un groupe.
  • Des autorisations ont été accordées à Tom via un système RBAC pris en charge.

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 peut 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é, un administrateur consent aux 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.

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 se voit attribuer des autorisations par le biais d’un système RBAC ou de rôles d’administration 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
  • Les utilisateurs peuvent donner leur consentement à leurs données
  • Les administrateurs peuvent donner leur consentement à tous les utilisateurs
    		•  Seul l’administrateur peut donner son consentement
    Autres noms
  • Étendues
  • Autorisations OAuth2
    		•
  • Rôles d’application
  • Autorisations d’application uniquement
  • Autorisations d’accès direct
    		•
    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é ou d’application uniquement.

    Illustration des privilèges d’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.

    RSC est une infrastructure d’autorisation qui permet d’accorder un accès étendu aux données exposées par une ressource. Par le biais de RSC, un utilisateur autorisé peut accorder à une application l’accès aux données d’un instance spécifique d’un type de ressource. Ils n’ont pas besoin d’accorder à l’application l’accès à chaque instance du type de ressource dans l’ensemble du locataire.

    Les autorisations RSC sont également disponibles pour le consentement et ne sont prises en charge que par un sous-ensemble de fonctionnalités disponibles via Microsoft Graph, telles que Teams, les conversations et les messages. En savoir plus sur les autorisations RSC ou découvrir 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 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 . Exemples : /groups/{id}/members, /users/{id}/memberOfet 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 se voit accorder l’autorisation GroupMember.Read.All avec le moindre privilège pour répertorier les membres du groupe. Dans l’objet response, seules les propriétés id et @odata.type sont renseignées pour tous les membres retournés. Les autres propriétés sont indiquées sous la forme null. Pour cette API :

    • 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.ReadBasic.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 GroupMember.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 , et ainsi de suite.
    • Toutefois, comme alternative aux autorisations individuelles au niveau de la ressource, l’application peut se voir attribuer au moins l’autorisation Directory.Read.All pour lire toutes les propriétés pour 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 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 GroupMember.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 augmente la surface d’attaque de l’application et l’expose à 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.

    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 précaution. Par exemple, l’autorisation Directory.AccessAsUser.All est l’autorisation déléguée avec privilèges le plus élevé 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 en lecture seule la plus privilégiée pour les ressources Microsoft Entra ID. Ces autorisations doivent être utilisées avec prudence et uniquement si nécessaire. Utilisez toujours des autorisations d’options avec des privilèges moindres à 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 supérieures peuvent être intentionnellement exclues de la table 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 pris en charge pour accéder à l’API en faveur des rôles avec des privilèges moindres.

    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