Types d’identité et de compte pour les applications monoclient et multiclients

Cet article explique comment vous, en tant que développeur, pouvez choisir si votre application autorise uniquement les utilisateurs de votre client Microsoft Entra, n’importe quel client Microsoft Entra ou les utilisateurs disposant de comptes Microsoft personnels. Vous pouvez configurer votre application pour qu'elle soit à client unique ou à clients multiples lors de l'inscription d’applications dans Azure. Veillez au principe de Confiance Zéro droit d'accès minimal afin que votre appli ne demande que les autorisations dont elle a besoin.

Le Plateforme d’identités Microsoft prend en charge des types d’identité spécifiques :

• Comptes professionnels ou scolaires lorsque l’entité possède un compte dans un Microsoft Entra ID
• Comptes personnels Microsoft (MSA) pour toute personne ayant un compte Outlook.com, Hotmail, Live, Skype, Xbox, etc.
• Identités externes dans Microsoft Entra ID pour les partenaires (utilisateurs en dehors de votre organisation)
• Microsoft Entra Business to Customer (B2C) qui vous permet de créer une solution qui permettra à vos clients d’apporter leurs autres fournisseurs d’identité. Les applications qui utilisent Azure AD B2C ou qui sont abonnées à Microsoft Dynamics 365 Fraud Protection avec Azure Active Directory B2C peuvent évaluer les activités potentiellement frauduleuses suite à des tentatives de création de comptes ou de connexion à l’écosystème du client.

Une partie requise de l’inscription d’application dans Microsoft Entra ID est votre sélection de types de comptes pris en charge. Bien que les professionnels de l’informatique dans les rôles d’administrateur décident qui peut donner leur consentement aux applications dans leur client, vous, en tant que développeur, spécifiez qui peut utiliser votre application en fonction du type de compte. Lorsqu’un client ne vous permet pas d’inscrire votre application dans Microsoft Entra ID, les administrateurs vous fournissent un moyen de communiquer ces détails avec eux via un autre mécanisme.

Vous choisirez parmi les options de type de compte prises en charge suivantes lors de l’inscription de votre application.

• Accounts in this organizational directory only (O365 only - Single tenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
• Personal Microsoft accounts only

Comptes dans ce répertoire d’organisation uniquement - client unique

Lorsque vous sélectionnez Comptes dans cet annuaire organisationnel uniquement (O365 uniquement - Client unique), vous autorisez uniquement les utilisateurs et les invités du locataire où le développeur a inscrit son application. Cette option est la plus courante pour les applications métier (LOB).

Comptes de tous les annuaires de l’organisation - multiclients

Lorsque vous sélectionnez Comptes dans n’importe quel annuaire organisationnel (n’importe quel annuaire Microsoft Entra - Multiclients), vous autorisez tout utilisateur à partir de n’importe quel annuaire Microsoft Entra à se connecter à votre application multi-clients. Si vous souhaitez autoriser uniquement les utilisateurs à partir de clients spécifiques, vous allez filtrer ces utilisateurs dans votre code en case activée que la revendication tid dans le id_token figure sur votre liste verte de clients. Votre application peut utiliser le point de terminaison des organisations ou le point de terminaison commun pour connecter des utilisateurs dans le client de base de l’utilisateur. Pour prendre en charge les utilisateurs invités qui se connectent à votre application multi-locataire, vous allez utiliser le point de terminaison de client spécifique pour le locataire où l’utilisateur est invité à se connecter à l’utilisateur.

Comptes dans n’importe quel compte professionnel et comptes Microsoft personnels

Lorsque vous sélectionnez Comptes dans n’importe quel compte professionnel et comptes Microsoft personnels (n’importe quel annuaire Microsoft Entra - Multilocataire) et comptes Microsoft personnels (par exemple, Skype, Xbox), vous autorisez un utilisateur à se connecter à votre application avec son identité native à partir de n’importe quel client Microsoft Entra ou compte consommateur. Le même filtrage de client et l’utilisation des points de terminaison s’appliquent à ces applications, car elles le font pour les applications multi-locataire, comme décrit ci-dessus.

Comptes Microsoft personnels uniquement

Lorsque vous sélectionnez des comptes Microsoft personnels uniquement, vous autorisez uniquement les utilisateurs disposant de comptes de consommateurs à utiliser votre application.

Applications destinées aux clients

Lorsque vous créez une solution dans le Plateforme d’identités Microsoft qui contacte vos clients, généralement vous ne souhaitez pas utiliser votre annuaire d’entreprise. Au lieu de cela, vous souhaitez que les clients se trouvent dans un annuaire distinct afin qu’ils ne puissent accéder à aucune des ressources d’entreprise de votre entreprise. Pour répondre à ce besoin, Microsoft propose Microsoft Entra Business to Customer (B2C).

Azure AD B2C fournit une identité entreprise-client en tant que service. Vous pouvez autoriser les utilisateurs à avoir un nom d’utilisateur et un mot de passe uniquement pour votre application. B2C prend en charge les clients disposant d’identités sociales pour réduire les mots de passe. Vous pouvez prendre en charge les clients d’entreprise en associant votre annuaire Azure AD B2C à l’ID Microsoft Entra de vos clients (ou à tout fournisseur d'identité prenant en charge SAML) à OpenID Connect. Contrairement à une application multi-locataire, votre application n’utilise pas l’annuaire d’entreprise du client où elle protège ses ressources d’entreprise. Vos clients peuvent accéder à votre service ou fonctionnalité sans accorder à votre application l’accès à leurs ressources d’entreprise.

Ce n’est pas seulement au développeur

Pendant que vous définissez dans l’inscription d’application qui peut se connecter à votre application, le dernier mot provient de l’utilisateur individuel ou des administrateurs du client domestique de l’utilisateur. Les admins clients veulent souvent avoir plus de contrôle sur une application qu’une seule personne pouvant se connecter. Par exemple, ils peuvent souhaiter appliquer une stratégie d’accès conditionnel à l’application ou contrôler le groupe qu’ils autorisent à utiliser l’application. Pour permettre aux admins clients d’avoir ce contrôle, il existe un deuxième objet dans la Plateforme d’identités Microsoft : l’application Entreprise. Les applications d’entreprise sont également appelées principaux de service.

Pour les applications avec des utilisateurs dans d’autres clients ou d’autres comptes de consommateurs

Comme illustré dans le diagramme ci-dessous à l’aide d’un exemple de deux locataires (pour les organisations fictives, Adatum et Contoso), les types de comptes pris en charge incluent les comptes dans n’importe quelle option d’annuaire organisationnel pour une application multi-locataire afin que vous puissiez autoriser les utilisateurs d’annuaire d’organisation. En d’autres termes, vous allez autoriser un utilisateur à se connecter à votre application avec son identité native à partir de n’importe quel Microsoft Entra ID. Un principal de service est créé automatiquement dans le client lorsque le premier utilisateur d’un locataire s’authentifie auprès de l’application.

L’image GIF animée montre deux diagrammes avec une transition de mouvement entre le premier diagramme et le deuxième diagramme. Premier titre du diagramme : principal de service créé automatiquement dans le locataire lorsque le premier utilisateur d’un client s’authentifie auprès de l’application. Sous le premier titre du diagramme, à gauche, sont deux points à puces : une seule inscription d’application ou un objet d'application. Application d’entreprise, principal de service, dans chaque client qui permet à l’utilisateur de se connecter à l’application. À gauche des points de puce, une forme cloud représente le client Adatum où Adatum est le nom d’une organisation fictive. Dans la forme cloud du client Adatum, une icône représente l’application et une autre icône représente le fournisseur de services Adatum. Une flèche connecte l’icône d’application à l’icône SP. Deuxième titre du diagramme : l’admin client contrôle le fonctionnement de l’application dans son client avec l’application Entreprise pour cette application. Sous le deuxième titre du diagramme, à gauche, une forme cloud représente le client Adatum où Adatum est le nom d’une organisation fictive. À droite de la forme cloud Adatum, une autre forme cloud représente le client Contoso où Contoso est le nom d’une organisation fictive. À l’intérieur de la forme cloud Contoso, une icône représente le fournisseur de services Contoso. Une flèche connecte l’application Adatum à l’intérieur de la forme cloud Adatum au SP Contoso à l’intérieur de la forme cloud Contoso.

Il n’existe qu’un seul objet d’inscription ou d’application. Toutefois, une application d’entreprise ou un principal de service (SP) dans chaque client permet aux utilisateurs de se connecter à l’application. L’admin client peut contrôler le fonctionnement de l’application dans son client.

Considérations relatives à l’architecture multi-locataire

Les applications multi-locataire connectent les utilisateurs à partir du locataire d’accueil de l’utilisateur lorsque l’application utilise le point de terminaison commun ou d’organisation. L’application possède une inscription d’application, comme illustré dans le diagramme ci-dessous. Dans cet exemple, l’application est inscrite dans le client Adatum. L’utilisateur A d’Adatum et l’utilisateur B de Contoso peuvent se connecter à l’application avec l’attente que l’utilisateur A d’Adatum accède aux données Adatum et que l’utilisateur B de Contoso accède aux données Contoso.

Titre du diagramme : Application multi-locataire et External Identities, également appelées B 2 B. À gauche, « Adatum » apparaît au-dessus d’un bâtiment pour représenter l’organisation Adatum où Adatum est le nom d’une organisation fictive. À droite, « Contoso » apparaît au-dessus d’un bâtiment pour représenter l’organisation Contoso où Contoso est le nom d’une organisation fictive. À droite du bâtiment Adatum est une zone avec le titre, Inscription d’application Adatum. Il contient une icône qui représente les données Adatum à gauche et une icône qui représente les données Contoso à droite. Une flèche connecte le bâtiment Adatum à la zone Inscription d’application Adatum. À l’intérieur du bâtiment Adatum, un cercle représente l’utilisateur A. Une flèche connecte l’utilisateur A à la zone inscriptions d'application Adatum. À l’intérieur du bâtiment Contoso, un cercle représente l’utilisateur B. Une flèche connecte l’utilisateur B à la zone Inscription d’application Adatum. Texte en bas du diagramme, entre les deux bâtiments : application multi-locataire. Utilise le point de terminaison commun pour se connecter. Aucun compte d’invitation/externe n’est nécessaire.

En tant que développeur, il est de votre responsabilité de séparer les informations du client. Par exemple, si les données Contoso proviennent de Microsoft Graph, l’utilisateur B de Contoso ne voit que les données Microsoft Graph de Contoso. Il n’existe aucune possibilité pour l’utilisateur B de Contoso d’accéder aux données Microsoft Graph dans le client Adatum, car Microsoft 365 a de vraies séparations de données.

Dans le diagramme ci-dessus, l’utilisateur B de Contoso peut se connecter à l’application et accéder aux données Contoso dans votre application. Votre application peut utiliser nos points de terminaison communs (ou organisation) afin que l’utilisateur se connecte en mode natif à son client, ce qui nécessite aucun processus d’invitation. Un utilisateur peut s’exécuter et se connecter à votre application, et il fonctionnera après que l’admin de l’utilisateur ou du client accorde son consentement.

Collaboration avec des utilisateurs externes

Lorsque les entreprises souhaitent permettre aux utilisateurs qui ne sont pas membres de l’entreprise d’accéder aux données de l’entreprise, ils utilisent la fonctionnalité Microsoft Entra Business to Business (B2B). Comme illustré dans le diagramme ci-dessous, les entreprises peuvent inviter les utilisateurs à devenir des utilisateurs invités dans leur client. Une fois que l’utilisateur a accepté l’invitation, il peut accéder aux données protégées par le client invitant. L’utilisateur ne crée pas d’informations d’identification distinctes dans le client.

Titre du diagramme : Application multi-locataire et identités externes, également appelées B 2 B. Sur la gauche, « Adatum » apparaît au-dessus d’un bâtiment pour représenter l’organisation Adatum. À droite, « Contoso » apparaît au-dessus d’un bâtiment pour représenter l’organisation Contoso. L’intérieur du bâtiment Contoso est un cercle qui représente l’utilisateur B. À droite du bâtiment Adatum, une zone contenant une icône représente les données Adatum et l’inscription d’application. Une flèche connecte le bâtiment Adatum à la zone de données et d’inscription. À l’intérieur du bâtiment Adatum, un cercle représente l’utilisateur A. Une flèche connecte l’utilisateur A à la zone de données et d’inscription. Un cercle plus petit à l’intérieur du bâtiment Adatum se connecte avec une flèche vers l’utilisateur B et une autre flèche vers la zone de données et d’inscription. Texte en bas du diagramme, entre les deux bâtiments : identités externes. Utilisez le point de terminaison Adatum pour vous connecter. Impossible d’utiliser un point de terminaison commun. Compte d’invitation/externe nécessaire.

Les utilisateurs invités s’authentifient en se connectant à leur client domestique, à leur compte Microsoft personnel ou à un autre compte fournisseur d’identité. Les invités peuvent également s’authentifier avec un code secret à usage unique à l’aide de n’importe quel email. Une fois les invités authentifiés, l’ID Microsoft Entra du client invitant fournit un jeton permettant d’accéder aux données du client invitant.

En tant que développeur, gardez ces considérations à l’esprit lorsque votre application prend en charge les utilisateurs invités :

• Vous devez utiliser un point de terminaison spécifique au locataire lors de la connexion à l’utilisateur invité. Vous ne pouvez pas utiliser les points de terminaison courants, d’organisation ou de consommateur.
• L’identité de l’utilisateur invité est différente de l’identité de l’utilisateur dans son client domestique ou dans un autre fournisseur d’identité. La revendication oid dans le jeton d’un utilisateur invité sera différente de celle de oid la même personne dans son client domestique.

Étapes suivantes

• Comment et pourquoi les applications sont ajoutées à Microsoft Entra ID explique comment les objets d’application décrivent une application à Microsoft Entra ID.
• Les meilleures pratiques de sécurité pour les propriétés d’application dans Microsoft Entra ID couvrent les propriétés telles que l’URI de redirection, les jetons d’accès, les certificats et les secrets, l’URI d’ID d’application et la propriété de l’application.
• La création d’applications avec une approche Confiance Zéro de l’identité fournit une vue d’ensemble des autorisations et des meilleures pratiques d’accès.
• L’acquisition d’une autorisation d’accès aux ressources vous aide à comprendre comment garantir le meilleur Confiance Zéro lors de l’acquisition d’autorisations d’accès aux ressources pour votre application.
• Le développement d’une stratégie de permissions déléguées vous aide à implémenter la meilleure approche pour gérer les autorisations dans votre application et à développer à l’aide de principes Confiance Zéro.
• Le développement d’une stratégie d’autorisations d’application vous aide à décider de l’approche des autorisations d’application pour le gestionnaire d'informations d’identification.