Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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 à locataire unique ou multilocataire lors de l’inscription de l’application dans Microsoft Entra. Assurez-vous que le principe confiance zéro de l’accès aux privilèges minimum est nécessaire pour que votre application demande uniquement des autorisations dont elle a besoin.
La 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 ID Microsoft Entra.
- 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).
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
Lorsque 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
Lorsque vous sélectionnez Comptes dans n’importe quel annuaire organisationnel (n’importe quel annuaire Microsoft Entra - Multilocataire), vous autorisez tout utilisateur à partir de n’importe quel annuaire Microsoft Entra à se connecter à votre application mutualisée. Si vous souhaitez autoriser uniquement les utilisateurs de certains locataires spécifiques, vous filtrez ces utilisateurs dans votre code en vérifiant que la revendication tid dans l'id_token figure sur 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.
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
Les types de comptes pris en charge incluent l'option des comptes dans n’importe quel annuaire organisationnel pour une application multi-entreprises, permettant ainsi d'autoriser les utilisateurs provenant de ces annuaires organisationnels. 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.
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.
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, 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.
Étapes suivantes
- Comment et pourquoi les applications sont ajoutées à l’ID Microsoft Entra explique comment les objets d’application décrivent une application à l’ID Microsoft Entra.
- 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 pour 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 des autorisations d’accès aux ressources pour votre application.
- Développer une stratégie d’autorisations déléguées vous aide à implémenter la meilleure approche pour gérer les autorisations dans votre application et à développer à l’aide des principes de confiance zéro.
- Développer une stratégie d’autorisations d’application vous aide à décider de l’approche des autorisations d’application pour la gestion des informations d’identification.