Configurer l’autorisation pour une application

  • 1 minute

Les administrateurs devront configurer les autorisations et le consentement dans le point de terminaison de la plateforme d’identités Microsoft.

Les applications qui s’intègrent à la plateforme d’identité Microsoft suivent un modèle d’autorisation permettant aux utilisateurs et aux administrateurs de contrôler l’accès aux données. L’implémentation de ce modèle d’autorisation a été mise à jour sur le point de terminaison de la plateforme d’identités Microsoft et elle modifie la façon dont une application doit interagir avec la plateforme d’identités Microsoft. Cette unité couvre les concepts de base de ce modèle d’autorisation, notamment les étendues, les autorisations et le consentement.

Étendues et autorisations

La plateforme d'identité Microsoft met en œuvre le protocole d'autorisation OAuth 2.0, une méthode par laquelle une application tierce peut accéder à des ressources hébergées sur le web au nom d'un utilisateur. Les ressources hébergées sur le web qui s’intègrent à la plateforme d’identité Microsoft présentent un identificateur de ressource, également appelé URI d’ID d’application. Par exemple, les ressources hébergées sur le web de Microsoft sont les suivantes :

  • 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 tierces intégrées à la plateforme d’identité Microsoft. Ces ressources peuvent également définir un ensemble d’autorisations à utiliser pour diviser la fonctionnalité de cette ressource en fragments plus réduits. Par exemple, Microsoft Graph a défini des autorisations pour des tâches telles que :

  • Lire le calendrier d’un utilisateur.
  • Écrire dans le calendrier d’un utilisateur.
  • Envoyer des messages en tant qu’utilisateur.

Quand l’application définit ces types d’autorisations, la ressource dispose d’un contrôle précis sur ses données et sur l’exposition de la fonctionnalité d’API. Une application tierce peut demander ces autorisations à des utilisateurs et des administrateurs. Ces derniers doivent approuver la requête avant que l’application puisse accéder aux données ou agir pour le compte d’un utilisateur. L’organisation de développement d’application peut regrouper les fonctionnalités des ressources en jeux d’autorisations plus petits, les développeurs peuvent créer des applications tierces qui demanderont uniquement les autorisations nécessaires à leur fonctionnement. Les utilisateurs et les administrateurs peuvent connaître avec précision les données auxquelles l’application a accès. Ainsi, ils seront moins inquiets quant à une éventuelle intention malveillante. Les développeurs doivent toujours respecter le concept de moindre privilège et demander uniquement les autorisations dont ils ont besoin pour faire fonctionner leurs applications.

Dans OAuth 2.0, ces types d’autorisations sont appelés des étendues. Ils sont également souvent appelés autorisations. Une autorisation est représentée dans la plateforme d’identité Microsoft sous forme de valeur de chaîne. Toujours dans l’exemple Microsoft Graph, la valeur de chaîne pour chaque autorisation est la suivante :

  • Lire le calendrier d’un utilisateur en utilisant Calendars.Read
  • Écrire dans le calendrier d’un utilisateur en utilisant Calendars.ReadWrite
  • Envoyer un e-mail en tant qu’utilisateur via Mail.Send

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 à privilèges élevés peuvent uniquement être accordées par le biais du consentement de l’administrateur. Elles sont demandées/accordées à l’aide du point de terminaison de consentement de l’administrateur.

Types d'autorisations

La plateforme d’identité Microsoft prend en charge deux types d’autorisations : les autorisations déléguées et les autorisations d’application.

  • Les autorisations déléguées sont utilisées par les applications pour lesquelles un utilisateur est connecté et présent. Pour ces applications, l’utilisateur ou un administrateur accorde les autorisations que l’application demande. Ensuite, l’application se voit déléguer une autorisation d’agir pour le compte de l’utilisateur connecté lors des appels à une ressource cible. Certaines autorisations déléguées peuvent être accordées par des utilisateurs non administrateurs, mais certaines autorisations à privilèges élevés requièrent le consentement de l’administrateur. Pour connaître les rôles administrateur habilités à donner leur consentement pour les autorisations déléguées, consultez Autorisations du rôle administrateur dans Microsoft Entra ID.
  • Les autorisations d’application sont utilisées par les applications qui s’exécutent sans qu’un utilisateur soit connecté et présent (les applications qui s’exécutent en tant que services ou démons en arrière-plan, par exemple). Seul un administrateur peut consentir aux permissions d’application.

Les autorisations effectives correspondent aux autorisations accordées à votre application lorsqu’elle envoie des requêtes à une ressource cible. Vous devez comprendre la différence entre les autorisations déléguées, les autorisations d’application et les autorisations effectives que votre application reçoit lorsqu’elle interroge la ressource cible.

  • Pour les autorisations déléguées, les autorisations effectives de votre application correspondent au niveau de privilège le moins élevé entre les autorisations déléguées que l’application a reçues (par le biais d’un consentement) et les privilèges de l’utilisateur actuellement connecté. Votre application ne peut jamais avoir plus de privilèges que l’utilisateur connecté. Au sein des organisations, les privilèges de l’utilisateur connecté sont déterminés par la stratégie ou l’appartenance à un ou plusieurs rôles d’administrateur. Pour connaître les rôles administrateur habilités à donner leur consentement pour les autorisations déléguées, consultez Autorisations du rôle administrateur dans Microsoft Entra ID.
  • Supposons que votre application ait reçu l’autorisation déléguée User.ReadWrite.All. Cette autorisation permet nominalement à votre application de lire et mettre à jour le profil de chaque utilisateur dans une organisation. Si l’utilisateur connecté est un administrateur général, votre application est en mesure de mettre à jour le profil de chaque utilisateur de l’organisation. Toutefois, si l’utilisateur connecté n’a pas de rôle d’administrateur, votre application peut uniquement mettre à jour le profil de l’utilisateur connecté. Elle ne peut pas mettre à jour les profils des autres utilisateurs de l’organisation, car l’utilisateur pour lequel elle est autorisée à agir n’a pas ces privilèges.
  • Pour les autorisations d’application, les autorisations effectives de votre application correspondent au niveau complet des privilèges impliqués par l’autorisation. Par exemple, une application disposant de l’autorisation d’application User.ReadWrite.All peut mettre à jour le profil de chaque utilisateur de l’organisation.

Étendues OpenId Connect

L'implémentation d'OpenID Connect sur la plateforme d'identités Microsoft comprend quelques étendues bien définies qui sont également hébergées sur l'instance de Microsoft Graph :openid, email, profile et offline_access. Les étendues « adress » et « phone » d’OpenID Connect ne sont pas prises en charge.

En demandant les étendues OIDC et un jeton, vous obtiendrez un jeton pour appeler le point de terminaison UserInfo.

Openid

Si une application exécute la connexion à l’aide d’OpenID Connect, elle doit solliciter l’étendue « openid ». L’étendue « openid » s’affiche sur la page de consentement du compte professionnel, en tant qu’autorisation sign you in, et sur la page de consentement du compte Microsoft personnel en tant qu’autorisation « Afficher votre profil et se connecter aux applications et aux services à l’aide de votre compte Microsoft ». Avec cette autorisation, une application peut recevoir un identifiant utilisateur unique sous la forme de la revendication « sub ». Elle permet également à l’application d’accéder au point de terminaison des informations utilisateur. L’étendue « openid » peut être utilisée sur le point de terminaison de jeton de la plateforme d’identité Microsoft pour acquérir des jetons d’ID, qui peuvent être utilisés par l’application pour l’authentification.

email

L’étendue « email » peut être utilisée avec l’étendue « openid » ainsi que d’autres. Elle permet à l’application d’accéder à l’adresse de messagerie principale de l’utilisateur sous la forme de la revendication « email ». La revendication « email » est incluse dans un jeton uniquement si une adresse e-mail est associée au compte d’utilisateur, ce qui n’est pas toujours le cas. Si elle utilise l’étendue « email », votre application doit être préparée à faire face à l’éventualité où la revendication « email » n’existerait pas dans le jeton.

profile

L’étendue « profile » peut être utilisée avec l’étendue « openid » ainsi que d’autres. Elle permet à l’application d’accéder à une quantité d’informations importante sur l’utilisateur, notamment le prénom de l’utilisateur, son nom de famille, son nom d’utilisateur privilégié et l’ID d’objet. Pour obtenir la liste complète des revendications de profil disponibles dans le paramètre « id_token » pour un utilisateur donné, consultez la page de référence « id_tokens ».

offline_access

L’étendue « offline_access » permet à votre application d’accéder aux ressources pour le compte de l’utilisateur pendant une période prolongée. Dans la page de consentement, cette étendue apparaît comme l’autorisation « Conserver l’accès aux données auxquelles vous lui avez donné l’accès ». Lorsqu’un utilisateur approuve l’étendue « offline_access », votre application peut recevoir des jetons d’actualisation du point de terminaison de jeton de plateforme d’identité Microsoft. Les jetons d’actualisation sont de longue durée. Votre application peut obtenir de nouveaux jetons d’accès lorsque les plus anciens arrivent à expiration.

Sur la plateforme d’identité de Microsoft (requêtes adressées au point de terminaison v 2.0), votre application doit demander explicitement à l’étendue « offline_access » de recevoir les jetons d’actualisation. Ainsi, lorsque vous échangez un code d’autorisation dans le flux de code d’autorisation OAuth 2.0, vous recevez uniquement un jeton d’accès du point de terminaison « /token ». Le jeton d’accès est valide pour une période de temps, qui expire généralement sous une heure. À ce stade, votre application doit rediriger l’utilisateur vers le point de terminaison « /authorize » afin de récupérer un nouveau code d’autorisation. Pendant ce réacheminement, en fonction du type d’application, l’utilisateur peut devoir entrer à nouveau ses informations d’identification ou accepter une nouvelle fois les autorisations.

Notes

Lorsque vous utilisez une application monopage (SPA), le jeton d’actualisation est toujours fourni.

Remarque

Cette autorisation s’affiche sur tous les écrans de consentement du jour, même pour les flux qui ne fournissent pas de jeton d’actualisation (le flux implicite). Cela permet de couvrir les scénarios dans lesquels un client peut commencer dans le cadre du flux implicite, puis passer au flux de code où un jeton d’actualisation est attendu.

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. Lorsqu’un utilisateur se connecte à une application, celle-ci envoie une demande d’autorisation. Le paramètre d’étendue est une liste de permissions 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 la permission déléguée 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, le point de terminaison de la plateforme d’identités Microsoft recherche un enregistrement correspondant du consentement d’utilisateur. Si, par le passé, l’utilisateur n’a jamais accepté les autorisations demandées et qu’un administrateur n’a jamais accepté ces autorisations pour le compte de toute l’organisation, le point de terminaison de la plateforme d’identités Microsoft demande à l’utilisateur d’accorder les autorisations demandées.

Remarque

À ce stade, les autorisations « offline_access » (« Conserver l’accès aux données auxquelles vous lui avez donné l’accès ») et « user.read » (« Vous connecter et lire votre profil ») sont automatiquement incluses dans le consentement initial pour une application. Ces autorisations sont généralement requises pour les fonctionnalités d’application appropriées. « offline_access » permet à l’application d’accéder à des jetons d’actualisation, essentiels pour les applications natives et web, tandis que user.read donne accès à la revendication « sub ». Ainsi, le client ou l’application peut identifier correctement l’utilisateur au fil du temps et accéder aux informations utilisateur rudimentaires.

Screenshot of the work account consent dialog. Users must agree to proceed with the application.

Lorsque l’utilisateur approuve la demande d’autorisation, le consentement est enregistré de manière à ce que l’utilisateur n’ait pas à le fournir à nouveau lors des connexions suivantes à l’application.

Souvent, quand une organisation achète une licence ou un abonnement pour une application, elle souhaite configurer proactivement l’application afin que tous les membres de l’organisation puissent l’utiliser. Dans le cadre de cette procédure, un administrateur peut autoriser l’application à agir au nom de n’importe quel utilisateur au sein du locataire. Si l’administrateur donne son consentement pour l’intégralité du locataire, les utilisateurs de l’organisation ne voient pas de page de consentement pour l’application. En outre, les applications doivent utiliser le point de terminaison du consentement administrateur pour demander des permissions d’application.