Partager via

Glossaire : plateforme d’identités Microsoft

  • Article

Vous rencontrez ces termes dans notre documentation, le centre d’administration Microsoft Entra, nos bibliothèques d’authentification et l’API Microsoft Graph. Certains termes sont spécifiques à Microsoft, tandis que d’autres sont liés à des protocoles comme OAuth ou d’autres technologies compatibles avec la plateforme d’identités Microsoft.

Access token (Jeton d’accès)

Un type de jeton de sécurité émis par un serveur d’autorisation et utilisé par une application cliente pour accéder à un serveur de ressources protégé. Apparaissant généralement sous la forme d’un jeton JSON Web Token (JWT), le jeton représente l’autorisation accordée au client par le propriétaire de la ressource pour un niveau d’accès demandé. Le jeton contient toutes les revendications applicables sur le sujet, permettant à l’application cliente de l’utiliser en guise d’informations d’identification lors de l’accès à une ressource donnée. Le propriétaire de la ressource n’a ainsi pas non plus besoin d’exposer ses informations d’identification au client.

Les jetons d’accès ne sont valides que pendant une brève période de temps et ne peuvent pas être révoqués. Un serveur d’autorisation peut également émettre un jeton d’actualisation lors de l’émission du jeton d’accès. Les jetons d’actualisation sont généralement fournis uniquement aux applications clientes confidentielles.

Les jetons d’accès sont parfois qualifiés de « utilisateur + Application » ou « d’application uniquement », selon les informations d’identification représentées. Par exemple, lorsqu’une application cliente utilise :

  • L’octroi d’autorisation « code d’autorisation », l’utilisateur final s’authentifie tout d’abord en tant que propriétaire de la ressource, délégant l’autorisation d’accès à la ressource au client. Le client s’authentifie après, lors de l’obtention du jeton d’accès. Le jeton est alors parfois désigné plus spécifiquement sous le nom de jeton « utilisateur + application », car il représente à la fois l’utilisateur qui a autorisé l’application cliente et l’application.
  • L’octroi d’autorisation « informations d’identification du client », le client fournit l’authentification unique, fonctionnant sans authentification/autorisation du propriétaire des ressources. Le jeton est alors parfois désigné sous le nom de jeton « d’application uniquement ».

Pour plus d'informations, consultez les informations de référence sur les jetons d'accès :

Acteur

Autre terme pour application cliente. L’acteur est la partie agissant pour le compte d’un sujet (propriétaire de la ressource).

ID d’application (client)

L'ID d'application, ou ID client, est une valeur que la plateforme d'identités Microsoft attribue à votre application lorsque vous l'enregistrez dans Microsoft Entra ID. L’ID d’application est une valeur GUID qui identifie de manière unique l’application et sa configuration au sein de la plateforme d’identités. Vous ajoutez l’ID d’application au code de votre application, et les bibliothèques d’authentification incluent la valeur dans leurs demandes à la plateforme d’identités au moment de l’exécution de l’application. L’ID d’application (client) n’est pas un secret. Ne l’utilisez pas comme mot de passe ou comme informations d’identification.

Manifeste d’application

Un manifeste de l’application est une fonctionnalité qui produit une représentation JSON de la configuration d’identité de l’application servant de mécanisme de mise à jour des entités Application et ServicePrincipal associées. Voir Comprendre le manifeste de l'application Microsoft Entra pour plus de détails.

Objet application

Lorsque vous inscrivez/mettez à jour une application, un objet d’application et un objet principal de service correspondant sont créés/mis à jour pour ce locataire. L’objet application définit la configuration d’identité de l’application de manière globale (sur tous les clients où elle dispose d’un accès) et fournit un modèle à partir duquel son ou ses objets principal du service correspondants sont dérivés à des fins d’utilisation locale lors de l’exécution (sur un client spécifique).

Pour plus d’informations, consultez Application and Service Principal Objects (Objets application et principaux du service).

Inscription de l’application

Afin de permettre à une application de s'intégrer et de déléguer des fonctions de gestion des identités et des accès à Microsoft Entra ID, elle doit être enregistrée auprès d'un locataire Microsoft Entra. Lorsque vous enregistrez votre application avec Microsoft Entra ID, vous fournissez une configuration d'identité pour votre application, lui permettant de s'intégrer à Microsoft Entra ID et d'utiliser des fonctionnalités telles que :

Voir Intégration d'applications avec Microsoft Entra ID pour plus de détails.

Authentification

Action de demander à une partie des informations d’identification légitimes, fournissant la base de la création d’un principal de sécurité à des fins de contrôle de l’identité et de l’accès. Pendant un octroi d’autorisation OAuth 2.0 par exemple, la partie s’authentifiant remplit le rôle de propriétaire de ressources ou d’application cliente, selon l’octroi utilisé.

Autorisation

Action de donner à un principal de sécurité authentifié le droit de faire quelque chose. Il existe deux cas d’utilisation principaux dans le modèle de programmation Microsoft Entra :

Code d’autorisation.

Valeur de courte durée fournie par le point de terminaison d’autorisation à une application cliente pendant le flux d’octroi de code d’autorisation OAuth 2.0, l’un des quatre octrois d’autorisation OAuth 2.0. Également appelé code d’authentification, le code d’autorisation est retourné à l’application cliente en réponse à l’authentification d’un propriétaire de ressources. Le code d’authentification indique que le propriétaire de ressources a délégué l’autorisation d’accès à ses ressources à l’application cliente. Dans le cadre de ce flux, le code d’authentification est ensuite échangé contre un jeton d’accès.

Point de terminaison d’autorisation

Un des points de terminaison implémentés par le serveur d’autorisation, utilisé pour interagir avec le propriétaire de ressources afin de fournir un octroi d’autorisation pendant un flux d’octroi d’autorisation OAuth 2.0. Selon le flux d’octroi d’autorisation utilisé, l’octroi fourni peut varier et prendre notamment la forme d’un code d’autorisation ou d’un jeton de sécurité.

Pour plus d’informations, consultez les types d’octroi d’autorisation et les points de terminaison d’autorisation de la spécification OAuth 2.0, ainsi que la spécification OpenIDConnect.

Octroi d’autorisation

Informations d’identification représentant l’autorisation accordée à une application cliente par le propriétaire des ressources d’accéder à ses ressources protégées. Une application cliente peut utiliser un des quatre types d’octroi définis par l’infrastructure d’autorisation OAuth 2.0 pour obtenir une autorisation, selon le type ou les exigences du client : octroi d’un code d’autorisation, octroi d’informations d’identification client, octroi implicite et octroi d’informations de mot de passe du propriétaire de la ressource. Les informations d’identification renvoyées au client prennent la forme d’un jeton d’accès ou d’un code d’autorisation (échangé plus tard contre un jeton d’accès), selon le type de flux d’octroi d’autorisation utilisé.

L’octroi d’informations d’identification de mot de passe du propriétaire de la ressource ne doit pas être utilisé, sauf dans les scénarios où d’autres flux ne peuvent pas être utilisés. Si vous créez une application monopage, utilisez le flux de code d’autorisation avec PKCE plutôt que l’octroi implicite.

Serveur d’autorisation

Comme le définit l’infrastructure d’autorisation OAuth 2.0, serveur responsable de l’émission de jetons d’accès pour le client après avoir authentifié le propriétaire des ressources et obtenu son autorisation. Une application cliente interagit avec le serveur d’autorisation lors de l’exécution via ses points de terminaison d’autorisation et de jeton, conformément aux octrois d’autorisation définis par l’infrastructure d’autorisation OAuth 2.0.

Dans le cas de l'intégration d'applications de la plateforme d'identités Microsoft, la plateforme d'identités Microsoft implémente le rôle de serveur d'autorisation pour les applications Microsoft Entra et les API de service Microsoft, par exemple les API Microsoft Graph.

Revendication

Les revendications sont des paires nom/valeurs dans un jeton de sécurité qui fournissent des assertions faites par une entité à une autre. Ces entités sont généralement l’application cliente ou un propriétaire de ressources fournissant des assertions à un serveur de ressources. Les revendications relaient des informations sur le sujet du jeton, comme l’ID du principal de sécurité authentifié par le serveur d’autorisation. Les revendications présentes dans un jeton peuvent varier et dépendent de plusieurs facteurs tels que le type de jeton, le type d’informations d’identification utilisées pour authentifier le sujet, la configuration de l’application, etc.

Consultez Informations de référence sur les jetons de la plateforme d’identités Microsoft pour en savoir plus.

Application cliente

Également appelé l’« acteur ». Comme le définit le framework d’autorisation OAuth 2.0, application qui effectue des demandes de ressources protégées au nom du propriétaire de ressources. Elle reçoit des autorisations du propriétaire de la ressource sous la forme d’étendues. Le terme « cliente » n’implique pas de caractéristiques d’implémentation matérielle particulières (par exemple, si l’application s’exécute sur un serveur, un ordinateur de bureau ou d’autres appareils).

Une application cliente demande l’autorisation à un propriétaire de ressources de participer à un flux d’octroi d’autorisation OAuth 2.0 et peut accéder aux API/données au nom du propriétaire de ressources. Le framework d’autorisation OAuth 2.0 définit deux types de clients, « confidentiel » et « public », en fonction de la capacité du client à préserver la confidentialité de ses informations d’identification. Les applications peuvent implémenter un client web (confidentiel) s’exécutant sur un serveur web, un client natif (public) installé sur un appareil ou un client basé sur un agent utilisateur (public) s’exécutant dans le navigateur d’un appareil.

Processus par lequel un propriétaire de ressources octroie à une application cliente l’accès à des ressources protégées avec des autorisations spécifiques, en son nom. Selon les autorisations demandées par le client, un administrateur ou un utilisateur sera invité à donner son consentement pour autoriser l’accès aux données de l’entreprise ou à ses données individuelles respectivement. Notez que dans un scénario d’application mutualisée, le principal du service de l’application est également enregistré dans le client de l’utilisateur donnant son consentement.

Consultez l’infrastructure de consentement pour plus d’informations.

Jeton d’ID

Jeton de sécurité OpenID Connect fourni par le point de terminaison d’autorisation d’un serveur d’autorisation et contenant des revendications se rapportant à l’authentification d’un propriétaire de ressources utilisateur final. Comme un jeton d’accès, un jeton d’ID est représenté sous forme de jeton JSON Web Token (JWT) signé numériquement. À la différence d’un jeton d’accès cependant, les revendications d’un jeton d’ID ne sont pas utilisés à des fins liées à l’accès aux ressources et plus particulièrement pour le contrôle d’accès.

Pour plus d'informations, consultez les informations de référence sur le jeton d'ID.

Identités managées

Éliminer la nécessité pour les développeurs de gérer les informations d’identification. Les identités gérées fournissent une identité que les applications peuvent utiliser lors de la connexion à des ressources prenant en charge l'authentification Microsoft Entra. Les applications peuvent utiliser l'identité managée pour obtenir des jetons de plateforme d'identité Microsoft. Par exemple, une application peut utiliser une identité managée pour accéder à des ressources comme Azure Key Vault où les développeurs peuvent stocker des informations d'identification de manière sécurisée, ou pour accéder à des comptes de stockage. Pour plus d’informations, consultez Vue d’ensemble des identités managées.

Plateforme d’identité Microsoft

La plateforme d'identité Microsoft est une évolution du service d'identité et de la plateforme de développement Microsoft Entra. Elle permet aux développeurs de générer des applications qui connectent toutes les identités Microsoft et obtiennent des jetons pour appeler Microsoft Graph, d’autres APIs Microsoft ou des API que des développeurs ont créées. C’est une plateforme complète qui se compose d’un service d’authentification, de bibliothèques, de fonctionnalités d’inscription et de configuration d’application, d’une documentation de développement exhaustive et d’exemples de code et autres contenus destinés aux développeurs. La plateforme d’identités Microsoft prend en charge les protocoles standard tels qu’OAuth 2.0 et OpenID Connect.

Application multilocataire

Classe d'application qui permet la connexion et le consentement des utilisateurs configurés dans n'importe quel locataire Microsoft Entra, y compris les locataires autres que celui dans lequel le client est enregistré. Les applications clientes natives sont mutualisées par défaut, tandis que les applications clientes web et ressources web/API peuvent choisir entre une architecture à client unique et une architecture mutualisée. Par opposition, une application web inscrite en tant qu’application à client unique permet uniquement des connexions depuis des comptes d’utilisateurs configurés dans le même client que celui dans lequel l’application est inscrite.

Consultez Comment connecter n’importe quel utilisateur Microsoft Entra à l’aide du modèle d’application mutualisée pour plus de détails.

Client natif

Type d’ application cliente installé en mode natif sur un appareil. Étant donné que tout le code est exécuté sur un appareil, il est considéré comme un client « public » en raison de son incapacité à stocker les informations d’identification de façon privée/confidentielle. Pour plus d’informations, consultez les types et profils de clients OAuth 2.0.

Autorisations

Une application cliente accède à un serveur de ressources en déclarant des demandes d’autorisation. Deux types sont disponibles :

Elles apparaissent également pendant le processus de consentement , donnant à l’administrateur ou au propriétaire des ressources la possibilité d’autoriser/de refuser l’accès client aux ressources de son client.

Vous pouvez configurer des requêtes d’autorisation sur la page API autorisées d’une application, en sélectionnant les « Autorisations déléguées » et les « Autorisations d’application » souhaitées (ces dernières nécessitent l’appartenance au rôle Administrateur général). Du fait qu’un client public ne peut pas conserver de façon sécurisée les informations d’identification, il peut demander uniquement des autorisations déléguées, alors qu’un client confidentiel peut demander des autorisations déléguées et des autorisations d’application. L’objet application du client stocke les autorisations déclarées dans sa propriété requiredResourceAccess.

Jeton d’actualisation

Type de jeton de sécurité émis par un serveur d’autorisation. Avant l’expiration d’un jeton d’accès, une application cliente inclut son jeton d’actualisation associé quand elle demande un nouveau jeton d’accès au serveur d’autorisation. Les jetons d’actualisation sont généralement au format JWT (JSON Web Token).

Contrairement aux jetons d’accès, les jetons d’actualisation peuvent être révoqués. Un serveur d’autorisation refuse toute demande provenant d’une application cliente qui comprend un jeton d’actualisation révoqué. Quand le serveur d’autorisation refuse une demande qui comprend un jeton d’actualisation révoqué, l’application cliente n’est plus autorisée à accéder au serveur de ressources pour le compte du propriétaire de ressources.

Pour en savoir plus, consultez les jetons d'actualisation.

Propriétaire de la ressource

Comme le définit le framework d’autorisation OAuth 2.0, entité capable d’octroyer l’accès à une ressource protégée. Quand le propriétaire de ressources est une personne, on le désigne sous le nom d’utilisateur final. Par exemple, lorsqu’une application cliente souhaite accéder à la boîte aux lettres d’un utilisateur via l’API Graph Microsoft, l’autorisation du propriétaire de ressources de la boîte aux lettres est nécessaire. Le « propriétaire de la ressource » est également parfois appelé le sujet.

Chaque jeton de sécurité représente un propriétaire de ressource. Le propriétaire de la ressource est ce que représentent la revendication de l’objet, la revendication de l’ID d’objet et les données personnelles dans le jeton. Les propriétaires de ressources sont le tiers qui accorde des autorisations déléguées à une application cliente, sous la forme d’étendues. Les propriétaires de ressources sont également les destinataires des rôles qui indiquent des autorisations étendues dans un locataire ou sur une application.

Serveur de ressources

Comme le définit le framework d’autorisation OAuth 2.0, serveur hébergeant des ressources protégées capable d’accepter et de répondre aux demandes de ressources protégées des applications clientes qui présentent un jeton d’accès. Également appelé serveur de ressources protégées ou application de ressources.

Un serveur de ressources expose des API et applique l’accès à ses ressources protégées via des étendues et des rôles, en s’appuyant sur l’infrastructure d’autorisation OAuth 2.0. Les exemples incluent l'API Microsoft Graph, qui donne accès aux données du locataire Microsoft Entra, et les API Microsoft 365 qui donnent accès à des données telles que la messagerie et le calendrier.

Tout comme une application client, la configuration de l'identité de l'application de ressources est établie via l'enregistrement dans un locataire Microsoft Entra, fournissant à la fois l'objet principal de l'application et du service. Certaines API fournies par Microsoft, telles que l’API Microsoft Graph, proposent des principaux du service préinscrits mis à disposition dans tous les clients lors du provisionnement.

Rôles

Comme les étendues, les rôles d’application offrent au serveur de ressources un moyen de régir l’accès à ses ressources protégées. Contrairement aux étendues, les rôles représentent des privilèges qui ont été accordés à l’objet au-delà de la base de référence. C’est pourquoi la lecture de votre propre adresse e-mail est une étendue, tandis qu’un administrateur de messagerie capable de lire l’adresse e-mail de tout le monde est un rôle.

Les rôles d’application peuvent prendre en charge deux types d’affectation : l’affectation d’« utilisateurs » implémente le contrôle d’accès en fonction du rôle pour les utilisateurs/groupes qui requièrent un accès à la ressource, tandis que l’attribution d’« applications » implémente le même contrôle pour les applications clientes qui requièrent un accès. Un rôle d’application peut être défini comme étant attribuable par un utilisateur, attribuable par une application, ou les deux.

Les rôles sont des chaînes définies par les ressources (par exemple, « Expense approver », « Read-only » ou « Directory.ReadWrite.All »), gérées par le manifeste de l’application de la ressource et stockées dans la propriété appRoles de cette dernière. Les utilisateurs peuvent être affectés à des rôles attribuables aux « utilisateurs » et les autorisations d’application cliente peuvent être configurées pour demander des rôles attribuables aux « applications ».

Pour une présentation détaillée des rôles d’application exposés par l’API Microsoft Graph, consultez Graph API Permission Scopes (Étendues des autorisations de l’API Graph). Pour obtenir un exemple d’implémentation pas à pas, consultez Ajouter ou supprimer des attributions de rôle Azure.

Étendues

Comme les rôles, les étendues offrent au serveur de ressources un moyen de régir l’accès à ses ressources protégées. Les portées sont utilisées pour implémenter un contrôle d’accès en fonction de la portée, pour une application cliente qui s’est vu attribuer un accès délégué à la ressource par son propriétaire.

Les étendues sont des chaînes définies par les ressources (par exemple, « Mail.Read » ou « Directory.ReadWrite.All »), gérées par le manifeste de l’application de la ressource et stockées dans la propriété oauth2Permissions de cette dernière. Les permissions déléguées de l’application cliente peuvent être configurées pour accéder à une étendue.

Une convention d’affectation de noms recommandée consiste à utiliser le format « ressource.opération.contrainte ». Pour une présentation détaillée des étendues exposées par l’API Microsoft Graph, consultez Graph API Permission Scopes (Étendues des autorisations de l’API Graph). Pour les étendues exposées par les services Microsoft 365, consultez Référence des autorisations des API Microsoft 365.

Jeton de sécurité

Document signé contenant des revendications, tel qu’un jeton OAuth 2.0 ou une assertion SAML 2.0. Pour un octroi d’autorisation OAuth 2.0, un jeton d’accès (OAuth2), un jeton d’actualisation et un jeton d’ID sont des types de jetons de sécurité qui sont tous implémentés au format JWT (JSON Web Token).

Objet principal du service

Lorsque vous inscrivez/mettez à jour une application, un objet d’application et un objet principal de service correspondant sont créés/mis à jour pour ce locataire. L’objet application définit la configuration d’identité de l’application de manière globale (sur tous les clients où l’application associée s’est vue octroyer un accès) et constitue le modèle à partir duquel son ou ses objets principal du service correspondants sont dérivés à des fins d’utilisation locale lors de l’exécution (sur un client spécifique).

Pour plus d’informations, consultez Application and Service Principal Objects (Objets application et principaux du service).

Connexion

Processus par lequel une application cliente lance l’authentification de l’utilisateur final et capture l’état associé pour demander un jeton de sécurité et délimiter la session de l’application à cet état. L’état peut inclure des artefacts tels que les informations de profil utilisateur et des informations dérivées des revendications de jeton.

La fonction d’ouverture de session d’une application est généralement utilisée pour mettre en œuvre l’authentification unique (SSO). Elle peut également être précédée d’une fonction « inscription », qui sert de point d’entrée pour qu’un utilisateur final accède à une application (lors de la première connexion). La fonction d’inscription sert à rassembler et à rendre persistant un état supplémentaire propre à l’utilisateur et peut nécessiter le consentement de l’utilisateur.

Se déconnecter

Processus de désactivation de l’authentification d’un utilisateur final par lequel l’état utilisateur associé à l’application cliente pendant la connexion est détaché.

Objet

Également appelé le propriétaire de la ressource.

Locataire

Une instance d'un annuaire Microsoft Entra est appelée client Microsoft Entra. Celui-ci fournit plusieurs fonctionnalités, notamment :

Les locataires Microsoft Entra sont créés/associés aux abonnements Azure et Microsoft 365 lors de l'inscription, fournissant ainsi des fonctionnalités de gestion des identités et des accès pour l’abonnement. Les administrateurs d'abonnement Azure peuvent également créer des locataires Microsoft Entra supplémentaires. Consultez Comment obtenir un locataire Microsoft Entra pour plus de détails sur les différentes manières d’accéder à un locataire. Consultez Associer ou ajouter un abonnement Azure à votre locataire Microsoft Entra pour plus de détails sur la relation entre les abonnements et un locataire Microsoft Entra, et pour obtenir des instructions sur la façon d'associer ou d'ajouter un abonnement à un locataire Microsoft Entra.

Point de terminaison de jeton

Un des points de terminaison implémentés par le serveur d’autorisation pour prendre en charge les octrois d’autorisation OAuth 2.0. En fonction de l’octroi, il peut être utilisé pour acquérir un jeton d’accès (et les jetons « d’actualisation » liés) à un client ou un jeton d’ID lorsqu’il est utilisé avec le protocole OpenID Connect.

Client basé sur un agent utilisateur

Type d’application cliente qui télécharge du code à partir d’un serveur web et s’exécute au sein d’un agent utilisateur (par exemple, un navigateur web), comme une application monopage (SPA). Étant donné que tout le code est exécuté sur un appareil, il est considéré comme un client « public » en raison de son incapacité à stocker les informations d’identification de façon privée/confidentielle. Pour plus d’informations, consultez les types et profils de clients OAuth 2.0.

Principal de l’utilisateur

De la même manière qu’un objet principal du service est utilisé pour représenter une instance d’application, un objet principal de l’utilisateur est un autre type de principal de sécurité, qui représente un utilisateur. Le type de ressource User Microsoft Graph définit le schéma d’un objet utilisateur, y compris les propriétés propres à l’utilisateur, telles que le nom et le prénom, le nom d’utilisateur principal, l’appartenance à un rôle d'annuaire, etc. Cela permet de fournir la configuration d’identité de l’utilisateur pour Microsoft Entra ID afin d’établir le principal d’un utilisateur à l’exécution. Le principal de l’utilisateur est utilisé pour représenter un utilisateur authentifié lors de l’authentification unique, de l’enregistrement de la délégation du consentement, de la prise de décisions de contrôle d’accès, etc.

Client web

Type d’application cliente qui exécute tout le code sur un serveur web et fonctionne comme un client confidentiel grâce au stockage sécurisé de ses informations d’identification sur le serveur. Pour plus d’informations, consultez les types et profils de clients OAuth 2.0.

Identité de charge de travail

Identité utilisée par une charge de travail logicielle (comme une application, un service, un script ou un conteneur) pour authentifier et accéder à d’autres services et ressources. Dans Microsoft Entra ID, les identités de charge de travail sont des applications, des principaux de service et des identités managées. Pour plus d’informations, consultez Vue d’ensemble de l’identité de charge de travail.

Fédération des identités de charge de travail

Vous permet d’accéder en toute sécurité aux ressources protégées par Microsoft Entra à partir d’applications et de services externes sans avoir besoin de gérer les secrets (pour les scénarios pris en charge). Pour plus d’informations, consultez Fédération d’identités de charge de travail.

Étapes suivantes

La plupart des termes de ce glossaire ont trait aux protocoles OAuth 2.0 et OpenID Connect. Bien que vous n’ayez pas besoin de savoir comment les protocoles fonctionnent « sur le réseau » pour utiliser la plateforme d’identités, vous pourrez plus facilement créer et déboguer l’authentification et l’autorisation dans vos applications en ayant quelques notions de base des protocoles :