Découvrir les autorisations et le consentement

  • 3 minutes

Les applications qui s’intègrent à la plateforme d’identités Microsoft suivent un modèle d’autorisation permettant aux utilisateurs et aux administrateurs de contrôler l’accès aux données.

La plateforme d’identités Microsoft implémente le protocole d’autorisation OAuth 2.0 . OAuth 2.0 est une méthode par le biais de laquelle une application tierce peut accéder aux ressources hébergées sur le web au nom d’un utilisateur. Toute ressource hébergée sur le web qui s’intègre à la plateforme d’identités Microsoft a un identificateur de ressource ou un URI d’ID d’application.

Voici quelques exemples de ressources Microsoft hébergées sur le web :

  • Microsoft Graph : https://graph.microsoft.com
  • API de messagerie Microsoft 365 : https://outlook.office.com
  • Azure Key Vault : https://vault.azure.net

Cela s’applique également aux ressources de tiers intégrées à la plateforme d’identités Microsoft. Ces ressources peuvent également définir un ensemble d’autorisations à utiliser pour diviser la fonctionnalité de cette ressource en plus petites parties. Lorsque les fonctionnalités d’une ressource sont regroupées en petits ensembles d’autorisations, des applications tierces peuvent être créées pour ne demander que les autorisations nécessaires à leur fonctionnement. Les utilisateurs et les administrateurs peuvent connaître les données auxquelles l’application peut accéder.

Dans OAuth 2.0, ces types de jeux d’autorisations sont appelés étendues. Elles sont également souvent appelées autorisations. Dans la plateforme d’identités Microsoft, une autorisation est représentée sous la forme d’une valeur de chaîne. Une application demande les autorisations dont elle a besoin en spécifiant l’autorisation dans le paramètre de requête scope. La plateforme d’identité prend en charge plusieurs étendues OpenID Connect bien définies et des autorisations basées sur les ressources (chaque autorisation est indiquée en ajoutant la valeur d’autorisation à l’IDENTIFICATEUR ou à l’URI de l’ID d’application de la ressource). Par exemple, la chaîne d’autorisation https://graph.microsoft.com/Calendars.Read est utilisée pour demander l’autorisation de lire les calendriers des utilisateurs dans Microsoft Graph.

Généralement, une application peut demander ces autorisations en spécifiant les étendues dans les demandes dirigées vers le point de terminaison d’autorisation de la plateforme d’identités Microsoft. Toutefois, certaines autorisations à haut privilège peuvent être accordées uniquement avec le consentement de l’administrateur. Ils peuvent être demandés ou accordés à l’aide du point de terminaison de consentement de l’administrateur.

Remarque

Dans les requêtes adressées aux points de terminaison d’autorisation, de jeton ou de consentement pour la plateforme d’identités Microsoft, si l’identificateur de ressource est omis dans le paramètre d’étendue, la ressource est censée être Microsoft Graph. Par exemple, scope=User.Read équivaut à https://graph.microsoft.com/User.Read.

Types d’autorisations

La plateforme d’identités Microsoft prend en charge deux types d’autorisations : l’accès délégué et l’accès aux applications uniquement.

  • L’accès délégué est utilisé par les applications qui ont un utilisateur connecté présent. Pour ces applications, l’utilisateur ou un administrateur consent aux autorisations demandées par l’application. L’application se voit déléguer la permission d’agir en tant qu’utilisateur connecté quand elle effectue des appels à la ressource cible.

  • Les autorisations d’accès uniquement aux applications sont utilisées par les applications qui s’exécutent sans utilisateur connecté présent, par exemple, les applications qui s’exécutent en tant que services ou démons en arrière-plan. Seul un administrateur peut consentir à des autorisations d’accès aux applications seules.

Les applications de la plateforme d’identités Microsoft s’appuient sur le consentement pour accéder aux ressources ou aux API nécessaires. Il existe de nombreux types de consentement dont votre application peut avoir besoin pour fonctionner correctement. Si vous définissez des autorisations, vous devez également comprendre la façon dont vos utilisateurs accèdent à votre application ou API.

Il existe trois types de consentement : consentement de l’utilisateur statique, consentementde l’utilisateur incrémentiel et dynamique et consentement de l’administrateur.

Dans le cadre d’un consentement de l’utilisateur statique, vous devez spécifier toutes les autorisations dont l’application a besoin dans sa configuration dans le portail Azure. Si l’utilisateur (ou l’administrateur, selon le cas) n’a pas octroyé son consentement pour cette application, la plateforme d’identités Microsoft invite l’utilisateur à donner son consentement à ce stade. Les autorisations statiques permettent également aux administrateurs de donner leur consentement au nom de tous les utilisateurs de l’organisation.

Bien que les autorisations statiques de l’application définies dans le portail Azure permettent de garder un code simple et agréable, elles présentent quelques problèmes potentiels pour les développeurs :

  • L’application doit demander toutes les autorisations dont elle est susceptible d’avoir besoin dès la première connexion de l’utilisateur. Ceci peut aboutir à une longue liste d’autorisations qui décourage les utilisateurs finaux d’approuver l’accès de l’application lors de la connexion initiale.

  • L’application doit connaître au préalable l’ensemble des ressources auxquelles elle est susceptible d’accéder. Il est difficile de créer des applications pouvant accéder à un nombre arbitraire de ressources.

Avec le point de terminaison de la plateforme d’identités Microsoft, vous pouvez ignorer les autorisations statiques définies dans les informations d’inscription de l’application du portail Azure et demander à la place des autorisations de façon progressive. Vous pouvez demander un ensemble minimal d’autorisations au préalable et en demander davantage au fur et à mesure que le client utilise plus de fonctionnalités d’application.

Pour cela, vous pouvez spécifier les étendues dont votre application a besoin à tout moment en incluant les nouvelles étendues dans le paramètre scope quand vous demandez un jeton d’accès, sans qu’il soit nécessaire de les définir au préalable dans les informations d’inscription de l’application. Si l’utilisateur n’a pas encore consenti aux nouvelles étendues ajoutées à la demande, il est invité à donner son consentement seulement aux nouvelles autorisations. Consentement incrémentiel ou dynamique, s’applique uniquement aux autorisations déléguées et pas aux autorisations d’accès aux applications seules.

Important

Le consentement dynamique peut s’avérer pratique, mais il représente un véritable défi pour les autorisations qui nécessitent un consentement de l’administrateur, dans la mesure où l’expérience du consentement administrateur n’a pas connaissance de ces autorisations au moment du consentement. Si vous avez besoin d’autorisations à privilège administratif ou si votre application utilise le consentement dynamique, vous devez inscrire toutes les autorisations dans le portail Azure (pas seulement le sous-ensemble d’autorisations qui nécessite le consentement de l’administrateur). Ceci permet aux administrateurs de locataires de donner leur consentement au nom de tous leurs utilisateurs.

Le consentement de l’administrateur est nécessaire quand votre application a besoin d’accéder à certaines autorisations à privilèges élevés. Le consentement de l’administrateur garantit que les administrateurs disposent d’autres contrôles avant d’autoriser des applications ou des utilisateurs à accéder aux données à privilèges élevés de l’organisation.

Quand il est recueilli pour le compte d’une organisation, le consentement de l’administrateur nécessite toujours les autorisations statiques inscrites pour l’application. Définissez ces autorisations pour les applications dans le portail d’inscription d’applications, si vous avez besoin qu’un administrateur donne son consentement au nom de l’ensemble de l’organisation. Cela permet de réduire les cycles nécessaires à l’administrateur de l’organisation pour configurer l’application.

Dans une demande d’autorisation OpenID Connect ou OAuth 2.0, une application peut demander les autorisations dont elle a besoin à l’aide du paramètre de requête d’étendue. Par exemple, lorsqu’un utilisateur se connecte à une application, cette dernière envoie une requête semblable à l’exemple ci-dessous. Les sauts de ligne sont ajoutés pour une meilleure lisibilité.

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

Le paramètre scope correspond à une liste d’autorisations déléguées séparées par des espaces, demandées par l’application. Chaque autorisation est indiquée par l’ajout de la valeur correspondante à l’identificateur de la ressource (URI d’ID d’application). Dans l’exemple de requête, l’application nécessite l’autorisation de lecture du calendrier de l’utilisateur et d’envoi de messages au nom de l’utilisateur.

Une fois que l’utilisateur a entré ses informations d’identification, la plateforme d’identités Microsoft recherche un enregistrement correspondant du consentement de l’utilisateur. Si, par le passé, l’utilisateur n’a consenti à aucune des autorisations demandées et que l’administrateur n’a pas consenti à ces autorisations pour le compte de toute l’organisation, la plateforme d’identités Microsoft demande à l’utilisateur d’accorder les autorisations demandées.