Partager via

Glossaire de la plateforme d’identités Microsoft

Ce glossaire explique les termes clés de la plateforme d’identités Microsoft, du Centre d’administration Microsoft Entra et de l’API Microsoft Graph. Découvrez les protocoles OAuth et les concepts d’authentification pour créer des applications sécurisées.

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 l’ID client est une valeur que la plateforme d’identités Microsoft attribue à votre application quand vous l’inscrivez 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 d’application est une fonctionnalité qui génère une représentation JSON de la configuration d’identité de l’application. Il est utilisé comme mécanisme pour mettre à jour les entités Application et ServicePrincipal associées. Consultez Fonctionnement du manifeste d’application Microsoft Entra pour plus de détails.

Objet application

Lorsque vous inscrivez ou mettez à jour une application, un objet d’application et un objet principal de service correspondant sont créés ou mis à jour pour ce locataire. L’objet d’application définit globalement la configuration d’identité de l’application (sur tous les locataires auxquels elle a accès), fournissant un modèle à partir duquel ses objets de principal de service correspondants sont dérivés pour une utilisation locale au moment de l’exécution (dans un locataire spécifique).

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

Inscription de l’application

Afin de pouvoir s’intégrer à Microsoft Entra ID et déléguer à ce service les fonctions de gestion de l’identité et de l’accès, l’application doit être inscrite auprès d’un locataire Microsoft Entra. Quand vous inscrivez votre application auprès de Microsoft Entra ID, vous fournissez une configuration d’identité pour votre application, ce qui permet à cette dernière de s’intégrer à Microsoft Entra ID et d’utiliser des fonctionnalités telles que :

Consultez 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ù les autres flux ne peuvent pas être utilisés. Si vous créez une SPA, utilisez le flux de code d’autorisation avec PKCE au lieu du flux d’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.

Réclamation

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 de 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.

Fournisseur d’identité

Un fournisseur d’identité est un service qui crée, gère et gère les informations d’identité pour les utilisateurs tout en fournissant des services d’authentification aux applications. Dans le contexte de Microsoft Entra, les fournisseurs d’identité peuvent inclure des comptes Microsoft et des fournisseurs d’identité sociale tels que Google ou Facebook en fonction de la configuration de votre locataire. Lorsqu’un utilisateur tente de se connecter, l’application redirige l’utilisateur vers le fournisseur d’identité approprié pour l’authentification.

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 la plateforme d’identités 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és 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 mutualisée

Classe d’applications qui permet aux utilisateurs configurés dans n’importe quel client Microsoft Entra, y compris ceux autres que celui où le client est enregistré, de se connecter et de donner leur consentement. Les applications clientes natives sont multilocataires par défaut, tandis que les applications client web et ressources web/API ont la possibilité de choisir entre un client unique ou un multilocataire. 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.

Pour plus d’informations, voir Comment se connecter en tant qu'utilisateur Microsoft Entra utilisant le modèle d'application multi-locataires.

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 dans la page Autorisations d’API 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. Citons, par exemple, l’API Microsoft Graph qui fournit un accès aux données du client Microsoft Entra, et les API Microsoft 365 qui fournissent un accès à des données telles que le courrier et le calendrier.

Tout comme une application cliente, la configuration d’identité d’une application de ressources est établie via l’inscription dans un client Microsoft Entra, fournissant à la fois l’objet application et l’objet principal 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 pouvant être affecté par l’utilisateur, assignable à l’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 via le manifeste d’application de la ressource et stockées dans la propriété appRoles de cette dernière. Les utilisateurs peuvent se voir attribuer des rôles « attribuables aux utilisateurs » et les autorisations des applications clientes 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.

Portées

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 portées sont des chaînes définies par les ressources (par exemple, « Mail.Read » ou « Directory.ReadWrite.All »), gérées via le manifeste d’application de la ressource et stockées dans la propriété oauth2Permissions de cette dernière. Les autorisations 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 ou mettez à jour une application, un objet d’application et un objet principal de service correspondant sont créés ou 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.

Déconnexion

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é.

Sujet

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

Locataire

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

Les locataires Microsoft Entra sont créés avec/associés à des abonnements Azure et Microsoft 365 pendant l’inscription, fournissant 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. Pour plus d’informations sur les diverses méthodes permettant d’accéder à un locataire, consultez Obtention d’un locataire Microsoft Entra. Pour plus d’informations sur la relation entre les abonnements et un locataire Microsoft Entra et pour obtenir des instructions sur l’association ou l’ajout d’un abonnement à un locataire Microsoft Entra, consultez Associer ou ajouter un abonnement Azure à votre locataire Microsoft Entra.

Les abonnés peuvent être configurés pour les scénarios relatifs au personnel ou externes. La configuration du locataire que vous choisissez dépend du type d’utilisateurs que vous souhaitez authentifier et autoriser dans votre application. Pour plus d’informations, consultez Fonctionnalités prises en charge dans la main-d’œuvre et les locataires externes.

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.

Flux utilisateur (locataires externes uniquement)

Un flux utilisateur est une stratégie prédéfinie et configurable qui définit les étapes à suivre par un utilisateur pour s’inscrire ou se connecter. Les flux utilisateur sont utilisés dans Microsoft Entra External pour fournir une expérience personnalisable pour les utilisateurs finaux. Ils vous permettent de définir le parcours utilisateur, y compris les fournisseurs d’identité utilisés, les attributs collectés et les options de personnalisation de l’interface utilisateur disponibles. Pour plus d’informations, consultez Créer un flux utilisateur dans Microsoft Entra External ID.

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 Usertype de ressource 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 de répertoire, etc. Cela permet de fournir la configuration d’identité utilisateur utilisée par Microsoft Entra ID pour établir le principal d’un utilisateur lors de 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 Microsoft Entra à partir d’applications et de services externes sans avoir à 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 :

  • Last updated on