Types d’identités et de comptes pour les applications monolocataires et multilocataires

Cet article explique comment, en tant que développeur, vous pouvez choisir si votre application autorise uniquement les utilisateurs de votre locataire Microsoft Entra, ceux de n’importe quel locataire Microsoft Entra ou ceux disposant de comptes Microsoft personnels. Vous pouvez configurer votre application pour qu’elle soit monolocataire ou multilocataire lors de l’inscription de l’application dans Microsoft Entra. 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 B2C (Business to Customer) vous permet de créer une solution qui permet à vos clients de faire appel à d’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. Quand un locataire ne vous autorise pas à inscrire votre application dans Microsoft Entra ID, les administrateurs vous offrent un moyen de leur communiquer ces détails via un autre mécanisme.

Vous avez le choix entre les options de type de compte pris 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

Quand vous sélectionnez Comptes dans cet annuaire organisationnel uniquement (O365 uniquement – Locataire 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

Quand vous sélectionnez Comptes dans un annuaire organisationnel (n’importe quel annuaire Microsoft Entra – Multilocataire), vous autorisez n’importe quel utilisateur de n’importe quel annuaire Microsoft Entra à se connecter à votre application multilocataire. Si vous souhaitez autoriser uniquement les utilisateurs provenant de locataires spécifiques, filtrez ces utilisateurs dans votre code en vérifiant que la revendication tid dans id_token figure dans votre liste autorisée de locataires. 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 multilocataire, utilisez le point de terminaison de locataire spécifique pour le locataire où l’utilisateur est un invité pour 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 locataire et l’utilisation du point de terminaison s’appliquent à ces applications de la même façon qu’aux applications multilocataires, comme décrit précédemment.

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 fédérant votre annuaire Azure AD B2C à l’annuaire Microsoft Entra ID de vos clients ou tout autre fournisseur d’identité prenant en charge le langage SAML (Security Assertion Markup Language) à 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 souhaitent peut-être 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.

Applications avec des utilisateurs dans d’autres locataires ou d’autres comptes de consommateurs

Comme vous pouvez le voir dans le diagramme suivant qui présente un exemple de deux locataires (pour les organisations fictives Adatum et Contoso), les types de comptes pris en charge incluent l’option Comptes dans un annuaire organisationnel pour une application multilocataire afin que vous puissiez autoriser les utilisateurs de l’annuaire organisationnel. En d’autres termes, vous autorisez un utilisateur à se connecter à votre application avec son identité native à partir de n’importe quel annuaire 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. 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.

Il n’existe qu’un seul objet d’inscription ou d’application. Toutefois, il existe dans chaque locataire une application d’entreprise, ou principal de service (SP, Service Principal), qui 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 a une inscription d’application, comme le montre le diagramme suivant. Dans cet exemple, l’application est inscrite dans le client Adatum. L’utilisateur A d’Adatum et l’utilisateur B de Contoso peuvent tous deux se connecter à l’application, en sachant que l’utilisateur A d’Adatum a accès aux données Adatum et que l’utilisateur B de Contoso a accès aux données Contoso.

Titre du diagramme : Application multilocataire et identités externes (ou B2B).

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 les points de terminaison courants (ou d’organisation) afin que l’utilisateur se connecte en mode natif à son locataire, sans nécessiter de processus d’invitation. Un utilisateur peut exécuter et se connecter à votre application, ce qui fonctionne une fois que l’administrateur de l’utilisateur ou du locataire donne 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 suivant, les entreprises peuvent inviter des utilisateurs à devenir des utilisateurs invités dans leur locataire. Si un utilisateur accepte l’invitation, il peut accéder aux données protégées par le locataire invitant. L’utilisateur ne crée pas d’informations d’identification distinctes dans le client.

Titre du diagramme : Application multilocataire et identités externes (ou B2B).

Les utilisateurs invités s’authentifient en se connectant à leur locataire d’accueil, à leur compte Microsoft personnel ou au compte d’un autre fournisseur d’identité (IDP). 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é est différente de la revendication oid de la même personne dans son locataire d’accueil.

É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.
• Acquérir l’autorisation d’accéder aux ressources vous aide à comprendre comment garantir la Confiance Zéro lors de l’acquisition d’autorisations d’accès aux ressources pour votre application.
• Développer 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 du code selon les principes de la Confiance Zéro.
• Développer une stratégie d’autorisations d’application vous aide à choisir une approche en matière d’autorisations d’application pour la gestion des informations d’identification.