Présentation de l’accès délégué

Lorsqu’un utilisateur se connecte à une application et l’utilise pour accéder à une autre ressource, comme Microsoft Graph, l’application doit d’abord demander l’autorisation d’accéder à cette ressource au nom de l’utilisateur. Ce scénario courant est appelé accès délégué.

Pourquoi utiliser l’accès délégué ?

Les gens utilisent fréquemment différentes applications pour accéder à leurs données à partir de services cloud. Par exemple, une personne peut vouloir utiliser son application PDF Reader favorite pour voir les fichiers stockés dans son OneDrive. Un autre exemple peut être l’application métier d’une entreprise qui peut récupérer des informations partagées sur ses collègues afin qu’elle puisse facilement choisir des réviseurs pour une demande. Dans ce cas, l’application cliente, PDF Reader, ou l’outil d’approbation de demande de l’entreprise doit être autorisé à accéder à ces données au nom de l’utilisateur qui s’est connecté à l’application.

Utilisez l’accès délégué chaque fois que vous voulez permettre à un utilisateur connecté de travailler avec ses propres ressources ou les ressources auxquelles il peut accéder. Qu’il s’agisse d’un administrateur configurant des stratégies pour l’ensemble de son organisation ou d’un utilisateur supprimant un e-mail dans sa boîte de réception, tous les scénarios impliquant des actions utilisateur doivent utiliser l’accès délégué.

En revanche, l’accès délégué est généralement un mauvais choix pour les scénarios qui doivent s’exécuter sans utilisateur connecté, comme l’automatisation. Ce n’est pas non plus un bon choix pour les scénarios qui impliquent l’accès aux ressources de nombreux utilisateurs, comme la protection contre la perte de données ou les sauvegardes. Envisagez d’utiliser un accès « application seule » pour ces types d’opérations.

Demande d’étendues en tant qu’application cliente

Votre application doit demander à l’utilisateur d’accorder une étendue spécifique, ou un ensemble d’étendues, pour l’application de ressources à laquelle vous souhaitez accéder. Les étendues peuvent également être appelées autorisations déléguées. Ces étendues décrivent les ressources et les opérations que votre application souhaite réaliser au nom de l’utilisateur. Par exemple, si vous souhaitez que votre application montre à l’utilisateur la liste des e-mails et des messages de chat récemment reçus, vous pouvez demander à l’utilisateur de donner son consentement aux étendues Mail.Read et Chat.Read Microsoft Graph.

Une fois que votre application a demandé une étendue, un utilisateur ou un administrateur doit accorder l’accès demandé. Les utilisateurs consommateurs qui ont des comptes Microsoft, comme des comptes Outlook.com ou Xbox Live, peuvent toujours accorder des étendues pour eux-mêmes. Les utilisateurs de l’organisation qui ont des comptes Microsoft Entra peuvent ou non être en mesure d’accorder des étendues, en fonction des paramètres de leur organisation. Si un utilisateur de l’organisation ne peut pas donner son consentement aux étendues directement, il doit demander à l’administrateur de son organisation de donner son consentement pour elles.

Suivez toujours le principe des privilèges minimum : ne demandez jamais des étendues dont votre application n’a pas besoin. Ce principe permet de limiter les risques au niveau sécurité si votre application est compromise et permet aux administrateurs d’accorder plus facilement l’accès à votre application. Par exemple, si votre application doit uniquement lister les conversations à laquelle appartient un utilisateur, mais qu’elle n’a pas besoin de montrer les messages de chat eux-mêmes, vous devez demander l’étendue Chat.ReadBasic Microsoft Graph, plus limitée que Chat.Read. Pour plus d’informations sur les étendues openID, consultez Étendues openID.

Conception et publication d’étendues pour un service de ressources

Si vous créez une API et que vous souhaitez autoriser l’accès délégué au nom des utilisateurs, vous devez créer des étendues que d’autres applications peuvent demander. Ces étendues doivent décrire les actions ou les ressources disponibles pour le client. Vous devez prendre en compte les scénarios de développeur lors de la conception de vos étendues.

Jeton à soi-même

Dans le scénario où :

• La ressource d’application et l’application cliente sont identiques.
• L’application n’a pas d’API web inscrite.
• L’application demande un jeton pour une autorisation déléguée pour s’expose elle-même

Aucun consentement n’est nécessaire ou affiché pour cette demande de jeton. En outre, on peut supposer que les applications créées au sein d’un locataire qui demandent un jeton à elles-mêmes ont déjà accès aux données de profil. Elles bénéficieront ainsi automatiquement de l’accès au profil.

Comment fonctionne l’accès délégué ?

La chose la plus importante à retenir concernant l’accès délégué est que votre application cliente et l’utilisateur connecté doivent tous deux avoir les bonnes autorisations. L’octroi d’une étendue ne suffit pas. Si l’application cliente n’a pas la bonne étendue ou si l’utilisateur n’a pas les droits suffisants pour lire ou modifier la ressource, l’appel échoue.

• Autorisation d’application cliente - Les applications clientes sont autorisées par l’octroi d’étendues. Lorsqu’une application cliente se voit octroyer une étendue par un utilisateur ou un administrateur pour accéder à des ressources, cet octroi est enregistré dans Microsoft Entra ID. Tous les jetons d’accès délégué qui sont demandés par le client pour accéder à la ressource au nom de l’utilisateur concerné contiennent alors les valeurs de revendication de ces étendues dans la revendication scp. L’application de ressources vérifie cette revendication pour déterminer si l’application cliente a reçu la bonne étendue pour l’appel.
• Autorisation utilisateur - Les utilisateurs sont autorisés par la ressource que vous appelez. Les applications de ressources peuvent utiliser un ou plusieurs systèmes pour l’autorisation utilisateur, tels que le contrôle d’accès en fonction du rôle, les relations de propriété/d’appartenance, les listes de contrôle d’accès ou autres vérifications. Par exemple, Microsoft Entra ID vérifie qu’un utilisateur a été affecté à un rôle d’administrateur de gestion d’applications ou d’administrateur général avant de l’autoriser à supprimer les applications d’une organisation, mais autorise également tous les utilisateurs à supprimer les applications dont ils sont propriétaires. De même, le service SharePoint Online vérifie qu’un utilisateur dispose des droits de propriétaire ou de lecteur appropriés sur un fichier avant de l’autoriser à l’ouvrir.

Exemple d’accès délégué – OneDrive via Microsoft Graph

Prenons l’exemple suivant :

Alice souhaite utiliser une application cliente pour ouvrir un fichier protégé par une API de ressource, Microsoft Graph. Pour l’autorisation utilisateur, le service OneDrive vérifie si le fichier est stocké dans le lecteur d’Alice. S’il est stocké dans le lecteur d’un autre utilisateur, OneDrive refuse la demande d’Alice et la définit comme non autorisée, car Alice n’a pas le droit de lire les lecteurs des autres utilisateurs.

Pour l’autorisation d’application cliente, OneDrive vérifie si l’étendue Files.Read a été accordée au client qui effectue l’appel au nom de l’utilisateur connecté. Dans le cas présent, l’utilisateur connecté est Alice. Si Files.Read n’a pas été accordé à l’application pour Alice, OneDrive refuse également la demande.

L’exemple donné est simplifié pour illustrer l’autorisation déléguée. Le service OneDrive de production prend en charge de nombreux autres scénarios d’accès, tels que les fichiers partagés.

Voir aussi

• Étendues openID Connect
• Rôles RBAC
• Vue d’ensemble des autorisations dans Microsoft Graph
• Informations de référence sur les autorisations Microsoft Graph