Partager via

Autoriser des applications, des ressources et des charges de travail avec Microsoft Entra ID

  • Article

Dans cet article, nous abordons le concept d’autorisation lorsqu’un humain interagit avec une application et la dirige lorsque les interfaces de programmation d’application (API) agissent pour un utilisateur. Nous abordons également les situations dans lesquelles les applications ou services fonctionnent indépendamment. Il s’agit du quatrième article d’une série sur la manière dont les développeurs de logiciels indépendants (ISV) peuvent créer et optimiser leurs applications pour Microsoft Entra ID. Dans cette série, vous pouvez en apprendre davantage sur ces sujets :

Autorisation dans les applications

Dans cette section, nous abordons les scénarios dans lesquels un humain interagit avec une application et la dirige. La section Autorisation dans les ressources (API) décrit comment les API effectuent l’autorisation lorsque l’utilisateur a besoin d’une autorisation pour accéder à une ressource, mais que Microsoft Entra ID n’effectue pas l’autorisation finale. La section Autorisation dans les charges de travail décrit les scénarios dans lesquels les applications ou services fonctionnent indépendamment.

Les applications ont besoin des autorisations suivantes lorsqu’elles doivent accéder aux ressources pour un utilisateur.

  • L’application doit avoir l’autorisation d’accéder à des opérations spécifiques au sein de ressources spécifiques pour l’utilisateur actuel.
  • L’utilisateur doit avoir l’autorisation d’accéder à une ressource dans les conditions actuelles.
  • L’utilisateur doit avoir l’autorisation d’accéder à une ressource.

Le processus d’autorisation commence par une application qui utilise OAuth 2.0 pour demander un jeton d’accès auprès de Microsoft Entra ID afin d’accéder à des opérations spécifiques au sein d’une ressource spécifique pour l’utilisateur. Dans l’accès délégué, une application agit en tant que délégué pour l’utilisateur.

Pour les développeurs, une ressource peut être une API, telle que Microsoft Graph ou Stockage Azure, ou leur propre API. Toutefois, la plupart des API ont différentes opérations, telles que la lecture et l’écriture. Lorsqu’une application lit uniquement à partir d’une API, l’application doit uniquement avoir l’autorisation pour les opérations de lecture. Cette approche protège une application contre la compromission et contre une utilisation pour plus d’accès que ce qu’a prévu le développeur. Le développeur suit le principe du privilège minimum lorsque son application autorise uniquement les opérations dont elle a besoin.

Pour désigner les opérations spécifiques dans une API spécifique dont a besoin une application, les développeurs utilisent le paramètre d’étendue d’une requête OAuth 2.0. Le concepteur d’API publie les étendues qu’une application peut demander dans le cadre de l’inscription d’application de l’API. Par exemple, les étendues de service Microsoft Power BI incluent ce qui suit.

Étendue du service Power BI Opérations
https://analysis.windows.net/powerbi/api/Capacity.Read.All L’application peut afficher toutes les capacités Power BI Premium et Power BI Embedded auxquelles l’utilisateur connecté a accès.
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All L’application peut afficher et modifier toutes les capacités Power BI Premium et Power BI Embedded auxquelles l’utilisateur connecté a accès.

Si une application lit uniquement les capacités, l’application demande l’étendue https://analysis.windows.net/powerbi/api/Capacity.Read.All. Si une application modifie les capacités, l’application demande alors l’étendue https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All.

L’étendue contient l’identité de l’API et l’identité de l’opération. Dans l’étendue https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All, l’API est https://analysis.windows.net/powerbi/api. L’opération est Capacity.ReadWrite.All. Compte tenu de la portée et de la popularité importantes de l’API Microsoft Graph, les développeurs peuvent demander des étendues pour Microsoft Graph sans le composant API de l’étendue. Par exemple, Microsoft Graph définit une étendue de https://graph.microsoft.com/Files.Read que les applications peuvent demander avec Files.Read au lieu d’utiliser le nom complet de l’étendue.

Pour terminer la première autorisation, une application doit avoir l’autorisation d’accéder à des opérations spécifiques au sein de ressources spécifiques pour l’utilisateur actuel, et Microsoft Entra ID doit d’abord authentifier l’utilisateur actuel. L’authentification unique (SSO) peut satisfaire cette authentification ou nécessiter une nouvelle interaction utilisateur.

Une fois que Microsoft Entra ID a identifié l’utilisateur, la solution vérifie si celui-ci a autorisé l’application pour l’étendue demandée. On appelle ce processus accorder le consentement. Si l’utilisateur a accordé son consentement, le processus d’autorisation peut continuer. Le consentement administrateur permet aux utilisateurs administrateurs de donner leur consentement pour eux-mêmes et pour l’ensemble de l’organisation. Microsoft Entra ID vérifie si l’application a le consentement administrateur pour une étendue. Si le consentement est accordé, le processus d’autorisation se poursuit.

Pendant la conception de l’étendue, un concepteur d’API peut désigner des étendues pour lesquelles seul un administrateur peut donner son consentement. Les étendues qui nécessitent le consentement administrateur représentent les opérations que le concepteur d’API considère comme plus sensibles, plus puissantes ou nécessitant une implication suffisante qu’un utilisateur non administrateur ne doit pas avoir l’autorité d’accorder à une application.

Bien que les concepteurs d’API soient les premiers à décider lesquelles de leurs étendues nécessitent un consentement administrateur, ils n’ont pas le dernier mot. Lorsqu’un concepteur d’API désigne une étendue pour qu’elle nécessite le consentement administrateur, l’étendue requiert alors toujours le consentement administrateur. Pour les étendues que le concepteur d’API ne désigne pas comme nécessitant le consentement administrateur, l’administrateur du locataire peut exiger un consentement administrateur ou un consentement progressif en fonction des risques, ce qui peut déterminer l’exigence de consentement administrateur. Les développeurs ne peuvent pas prédire si une demande de jeton nécessite le consentement administrateur. Toutefois, cette limitation n’affecte pas le code nécessaire. Le refus de consentement n’est qu’une des nombreuses raisons pour lesquelles une demande de jeton peut être refusée. Les applications doivent toujours gérer correctement le fait de ne pas recevoir de jeton.

Si l’utilisateur ou l’administrateur n’a pas accordé le consentement, l’utilisateur voit alors une invite de consentement, comme illustré dans l’exemple suivant.

Capture d’écran de l’invite de consentement de l’utilisateur.

Les invites de consentement de l’utilisateur administrateur peuvent lui permettre de sélectionner Consentement pour le compte de votre organisation pour accorder le consentement pour tous les utilisateurs du locataire, comme illustré dans l’exemple suivant.

Capture d’écran de l’invite de consentement administrateur.

Les applications contrôlent le timing des invites de consentement de l’utilisateur. Microsoft Entra ID prend en charge le consentement statique : lorsqu’une application utilise l’étendue .default, l’application demande toutes les autorisations déclarées dans l’inscription de l’application. Avec le consentement statique, votre application demande à l’avance toutes les autorisations dont elle pourrait avoir besoin.

Le consentement statique peut décourager les utilisateurs et les administrateurs d’approuver la demande d’accès de votre application. La meilleure pratique pour le processus de demande de consentement consiste à demander les autorisations requises de façon dynamique pour la fonctionnalité de base de votre application au démarrage de celle-ci, puis de demander davantage d’étendues si nécessaire. Demandez de manière incrémentielle davantage d’étendues lorsque l’application effectue des opérations qui ont besoin de ces étendues. Cette approche offre à l’utilisateur une meilleure compréhension des autres autorisations qui entrent en corrélation dans le timing des fonctionnalités. Pour chaque jeton d’accès d’API, Microsoft Entra ID inclut toutes les étendues précédemment accordées à une application, pas seulement les étendues qui font l’objet de la requête.

Par exemple, une application peut demander https://graph.microsoft.com/user.read pour connecter l’utilisateur et accéder à son profil au démarrage de celle-ci. Plus tard, un utilisateur sélectionne Enregistrer dans OneDrive et l’application demande https://graph.microsoft.com/files.readwrite pour écrire un fichier dans le OneDrive de l’utilisateur. Étant donné que l’utilisateur voit pourquoi une application demande d’écrire dans son OneDrive, l’utilisateur accorde l’autorisation et l’application enregistre un fichier dans le OneDrive de l’utilisateur. L’utilisateur ferme ensuite l’application. Lorsque l’application démarre la fois suivante, elle demande https://graph.microsoft.com/user.read. Microsoft Entra ID retourne un jeton d’accès avec les étendues https://graph.microsoft.com/user.read et https://graph.microsoft.com/files.readwrite. Une demande de jeton pour l’étendue https://graph.microsoft.com/files.readwrite ne nécessite pas de consentement, car l’utilisateur l’a accordé. Dans les bibliothèques d’authentification Microsoft (MSAL) la mise en cache des jetons en fonction des autorisations accordées est automatiquement gérée. Dans cet exemple, après le redémarrage de l’application, les appels à la bibliothèque MSAL pour acquérir un jeton avec l’étendue https://graph.microsoft.com/files.readwrite retournent le jeton mis en cache à partir de la demande initiale de l’application pour l’étendue https://graph.microsoft.com/user.read. Un autre appel à Microsoft Entra ID n’est pas nécessaire.

Le consentement dynamique et le consentement incrémentiel ne nécessitent aucune autorisation déclarée lors de l’inscription d’application. Toutefois, nous recommandons vivement que les applications déclarent toutes les autorisations dont une application pourrait avoir besoin dans une inscription d’application pour prendre en charge le consentement statique. Les administrateurs peuvent accorder le consentement administrateur dans le Centre d’administration Microsoft Entra en utilisant Microsoft Graph PowerShell ou avec l’API Microsoft Graph.

Afin d’accorder le consentement administrateur pour une application, le Centre d’administration Microsoft Entra utilise le consentement statique en demandant le consentement avec l’étendue .default pour une application. Les administrateurs ne peuvent pas, dans le Centre d’administration Microsoft Entra, accorder le consentement administrateur aux applications qui nécessitent une autorisation si les développeurs ne les déclarent pas dans l’inscription d’application.

Les clients Microsoft Entra ID peuvent utiliser des stratégies d’accès conditionnel pour protéger les ressources (API) et les applications basées sur un navigateur. Par défaut, les administrateurs ne peuvent pas appliquer de stratégies d’accès conditionnel aux authentifications d’applications natives. Les administrateurs du locataire peuvent cibler Toutes les ressources (anciennement appelée « Toutes les applications clouds») ou utiliser des attributs de sécurité personnalisés pour cibler les applications natives avec des stratégies d’accès conditionnel. Même lorsque les stratégies sont ciblées, leur application exclut certaines applications qui accèdent à Microsoft Graph ou à Microsoft Azure AD Graph.

Les applications ne nécessitent généralement pas de code spécial pour l’accès conditionnel, sauf si les scénarios suivants s’appliquent.

  • Les applications qui effectuent le flux Pour le compte de
  • Les applications qui accèdent à plusieurs services ou ressources
  • Les applications monopages qui utilisent MSAL.js
  • Les applications web qui appellent une ressource

Si votre application implémente l’un de ces scénarios, consultez les Conseils aux développeurs pour l’accès conditionnel Microsoft Entra.

Les locataires Microsoft Entra ID gratuits ne peuvent pas utiliser l’accès conditionnel (voir les conditions de licence). Le locataire de production de votre entreprise peut avoir la licence requise. Évaluez ces conditions avant d’utiliser votre locataire de production pour les tests. Il existe des conseils pour créer un locataire de test.

Par défaut, les stratégies d’accès conditionnel s’appliquent aux applications et aux ressources auxquelles une application accède au niveau de l’application. Les administrateurs informatiques peuvent appliquer des stratégies au niveau de l’application quelle qu’elle soit sans participation du développeur. Certaines applications et certains scénarios nécessitent plus de granularité. Par exemple, une application financière peut nécessiter une authentification multifacteur pour une utilisation classique. Toutefois, une transaction sur un montant désigné peut nécessiter un appareil géré. Les développeurs peuvent permettre aux administrateurs informatiques d’attribuer des stratégies d’accès conditionnel progressives à différentes zones d’une application en implémentant le contexte d’authentification d’accès conditionnel. Le Guide du développeur sur le contexte d’authentification de l’accès conditionnel est une excellente référence pour ces fonctionnalités.

Par défaut, Microsoft Entra ID émet des jetons d’accès valides pendant une durée donnée. Les applications ne doivent jamais supposer la durée de vie d’un jeton. Elles doivent utiliser le paramètre expires_in que Microsoft Entra ID retourne avec le jeton d’accès. MSAL gère automatiquement ce scénario. Pendant la durée de vie du jeton d’accès, l’utilisateur a l’autorisation d’accéder à la ressource en vertu des conditions au moment de l’autorisation.

Le décalage entre le moment où les conditions changent et le moment où les modifications de stratégie sont appliquées peut concerner les administrateurs et les utilisateurs. Par exemple, lorsqu’un utilisateur perd un appareil, l’administrateur informatique peut révoquer les sessions de l’utilisateur. Toutefois, une application sur l’appareil perdu peut continuer d’accéder à Microsoft Graph pour l’utilisateur jusqu’à l’expiration du jeton. L’évaluation continue de l’accès (CAE) Microsoft peut empêcher l’accès après la révocation des sessions utilisateur pour les applications qui adoptent CAE. Si votre application appelle Microsoft Graph au moins une fois par heure, vous pouvez adopter CAE. Le Guide pratique pour utiliser les API d’évaluation continue de l’accès dans vos applications fournit des détails d’implémentation.

Si vous ne pouvez pas générer sur MSAL, votre application doit utiliser OAuth 2.0 pour demander des jetons d’accès à partir de Microsoft Entra ID. L’article Plateforme d’identités Microsoft et flux de code d’autorisation OAuth 2.0 fournit des détails d’implémentation pour les flux pris en charge par Microsoft Entra ID.

Si vous créez des applications pour appareil mobile, consultez Prendre en charge l’authentification unique et les stratégies de protection des applications dans vos applications mobiles. Découvrez comment prendre en charge l’acquisition de jetons, la gestion des applications mobiles Intune (MAM) et les stratégies de protection des applications.

Autorisation dans les ressources (API)

La section Autorisation dans les applications a introduit trois autorisations requises lorsque les applications doivent accéder à des ressources pour un utilisateur, mais n’a traité que les deux premières. L’utilisateur doit avoir l’autorisation d’accéder à une ressource, mais Microsoft Entra ID n’effectue pas l’autorisation finale. La ressource (API) effectue l’autorisation.

Les API doivent appliquer deux autorisations lorsqu’elles agissent pour un utilisateur :

  • Les API doivent autoriser une application à appeler l’API. Vérifiez que la revendication scp (étendue) du jeton d’accès contient l’étendue requise.
  • Les API doivent autoriser l’utilisateur à accéder à la ressource spécifique. Les revendications oid (ID d’objet) et sub (objet) du jeton représentent l’identité de l’utilisateur.

Nous recommandons les revendications oid et sub pour l’autorisation.

Microsoft Entra ID implémente une revendication sub par paire, ce qui signifie que la revendication sub est un identifiant utilisateur unique pour l’application qui effectue la demande. Le même utilisateur utilisant une autre application a une revendication sub différente. La revendication oid est constante pour l’utilisateur pour toutes les applications.

Les applications fournissent le jeton d’accès requis aux API que Microsoft Entra ID protège dans l’en-tête d’autorisation de la demande http en tant que jeton du porteur. Les API doivent entièrement valider le jeton reçu, car celui-ci ne provient pas directement de Microsoft Entra ID. Considérez l’application appelante comme non fiable jusqu’à la validation du jeton. Les articles sur la référence de jeton d’accès et la référence de validation des revendications fournissent des détails sur la validation des jetons d’accès Microsoft Entra ID.

Microsoft Entra ID publie les clés publiques utilisées par les API pour valider la signature du jeton. Ces clés sont substituées régulièrement et chaque fois que la situation nécessite une substitution de clé publique. Votre application ne doit jamais supposer qu’il existe un calendrier défini pour la substitution de clé publique. L’article Substitution de clé de signature dans la plateforme d’identités Microsoft explique comment gérer correctement la substitution de clé publique.

Nous vous recommandons d’utiliser une bibliothèque parfaitement tenue à jour pour effectuer la validation des jetons. Si vous créez une application web ou une API sur ASP.NET ou ASP.NET Core, utilisez Microsoft.Identity.Web pour gérer la validation des jetons. L’article du guide pratique API web protégée explique comment utiliser Microsoft.Identity.Web pour protéger une API.

Les API doivent parfois appeler d’autres API. Lorsqu’une application fonctionne pour l’utilisateur, l’API reçoit un jeton d’accès délégué qui inclut l’identité de l’utilisateur actuel. Il est important que l’API fasse uniquement confiance à un jeton validé à partir de Microsoft Entra ID pour déterminer l’identité de l’utilisateur actuel. Cette approche empêche une éventuelle compromission de l’application lorsque des utilisateurs empruntent l’identité d’autres utilisateurs et accèdent à des ressources pour un autre utilisateur. Pour cette même protection lorsqu’une API appelle une autre API, utilisez le flux OAuth On Behalf Of pour acquérir un jeton d’accès pour appeler une API pour le compte de l’utilisateur pour lequel l’API a été appelée. L’article Générer une API web qui appelle des API web fournit des étapes permettant à une API d’appeler d’autres API pour l’utilisateur actuel de l’application.

Outre l’accès délégué, les API peuvent avoir besoin de prendre en charge des applications et d’agir indépendamment sans les utilisateurs actuels. Microsoft Entra ID fait référence à ces applications en tant que charges de travail. Pour appliquer l’autorisation des charges de travail, les API n’utilisent pas la revendication scp (étendue). À la place, les API utilisent la revendication roles pour valider qu’une charge de travail a le consentement requis. Les API sont responsables de s’assurer que la charge de travail a l’autorisation d’accéder à la ressource.

Autorisation dans les charges de travail

Les charges de travail sont des applications qui fonctionnent indépendamment et n’ont pas d’utilisateur actuel. Comme pour l’accès délégué décrit dans la section Autorisation dans les applications, l’accès de l’application uniquement nécessite plusieurs autorisations :

  • L’application doit avoir l’autorisation d’accéder à des opérations spécifiques au sein de ressources spécifiques.
  • L’application doit avoir l’autorisation d’accéder à la ressource dans les conditions actuelles.
  • L’application doit avoir l’autorisation d’accéder à la ressource.

Le processus commence par une charge de travail demandant un jeton d’accès avec l’étendue .default (par exemple, https://graph.microsoft.com/.default). Contrairement à l’accès délégué (les applications peuvent demander de façon dynamique et incrémentielle des étendues), les charges de travail doivent toujours utiliser le consentement statique et l’étendue .default.

Les concepteurs d’API créent des autorisations d’application pour leur API en ajoutant des rôles à l’inscription d’application de l’API. Ces rôles ont le type de membre autorisé applications, ce qui permet l’attribution de rôle aux charges de travail. Attribuer des rôles aux charges de travail dans le Centre d’administration Microsoft Entra ou avec Microsoft Graph. Dans le Centre d’administration Microsoft Entra, le consentement administrateur pour les rôles attribués est nécessaire avant que la charge de travail puisse s’exécuter.

Par défaut, une autorisation d’application autorise les charges de travail à accéder à toutes les instances d’une ressource. Par exemple, https://graph.microsoft.com/user.read.all autorise une charge de travail à accéder au profil utilisateur complet de chaque utilisateur du locataire. Les administrateurs informatiques sont souvent réticents à accorder ces autorisations générales.

Pour les charges de travail qui accèdent à Microsoft Graph, utilisez ces méthodes pour limiter l’autorisation d’application :

Contrairement aux applications avec des utilisateurs, les charges de travail s’authentifient auprès de Microsoft Entra ID.

Pour les charges de travail qui s’exécutent dans Microsoft Azure, les identités managées pour les ressources Azure constituent la meilleure méthode pour qu’une charge de travail s’authentifie elle-même. La fonctionnalité d’identités managées élimine la nécessité de gérer les informations d’identification pour la charge de travail. Il n’existe pas d’informations d’identification accessibles. Microsoft Entra ID gère entièrement les informations d’identification. Sans informations d’identification à gérer, aucune information d’identification ne court le risque d’être compromise.

Avec une sécurité accrue, les identités managées augmentent également la résilience. Les identités managées utilisent des jetons d’accès à durée de vie étendue et des informations provenant de Microsoft Entra ID pour acquérir de nouveaux jetons avant l’expiration des jetons plus anciens. Les identités managées utilisent des points de terminaison régionaux qui permettent d’éviter les défaillances hors région en consolidant les dépendances du service. Les points de terminaison régionaux servent à conserver le trafic dans une zone géographique. Par exemple, si votre ressource Azure est installée à WestUS2, tout le trafic reste à WestUS2.

Si la charge de travail n’est pas en cours d’exécution dans Microsoft Azure, elle doit s’authentifier en utilisant le flux des informations d’identification client OAuth 2.0.

Microsoft Entra ID prend en charge ces types d’informations d’identification client :

  • Certificat. Les charges de travail prouvent qu’elles possèdent une clé privée en signant une assertion avec cette clé privée. La clé privée n’est pas transmise à Microsoft Entra ID. Seule l’assertion est envoyée. Nous vous recommandons des certificats plutôt que des clés secrètes clients, car ils sont plus sécurisés et souvent mieux gérés.
  • Informations d’identification fédérées. La fédération d’identités de charge de travail permet aux charges de travail qui ne sont pas en cours d’exécution sur Microsoft Azure d’utiliser une identité d’un autre fournisseur d’identité, GitHub Actions ou cluster Kubernetes. Les charges de travail demandent des jetons de la même manière pour les informations d’identification fédérées et pour les informations d’identification de certificat. La différence est que l’assertion, un JSON Web Token signé, provient du fournisseur d’identité de fédération.
  • Clé secrète client. Parfois appelé mot de passe d’application, la clé secrète client est une valeur de chaîne que la charge de travail peut utiliser pour s’identifier elle-même. La valeur texte du secret est envoyée de la charge de travail à Microsoft Entra ID dans une requête POST pour un jeton. Les clés secrètes clients sont moins sécurisées que les certificats ou la fédération d’identité de charge de travail. Si votre charge de travail utilise des secrets, suivez ces meilleures pratiques pour gérer les secrets.

En plus de Microsoft Entra ID, la famille de produits Microsoft Entra inclut Microsoft Entra Workload ID. Microsoft Entra Workload ID propose les fonctionnalités Premium suivantes pour améliorer la sécurité des charges de travail.

  • Accès conditionnel : prend en charge les stratégies basées sur l’emplacement ou le risque lié aux identités de charge de travail.
  • Protection des ID Microsoft Entra : fournit des rapports sur les informations d’identification compromises, les connexions anormales et les modifications suspectes apportées aux comptes.
  • Révisions d’accès : permettent la délégation des révisions aux bonnes personnes, en se concentrant sur les rôles privilégiés les plus importants.
  • Recommandations d’intégrité des applications : suggèrent des moyens de résoudre les lacunes d’intégrité des identités dans votre portefeuille d’applications et d’améliorer la sécurité du locataire et la posture de résilience.

Les charges de travail peuvent prendre en charge l’évaluation continue de l’accès (CAE) si elles appellent Microsoft Graph au moins une fois par heure. Pour prendre en charge CAE, la charge de travail doit être une application locataire unique et l’application inscrite dans le locataire où elle accède à Microsoft Graph. Si votre charge de travail répond à ces exigences, consultez cet exemple pour connaître les étapes d’implémentation.

Étapes suivantes