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

Cet article explique comment vous, en tant que développeur, pouvez choisir si votre application autorise uniquement les utilisateurs de votre locataire Azure Active Directory (Azure AD), n’importe quel locataire Azure AD ou les utilisateurs disposant de comptes Microsoft personnels en configurant votre application pour qu’elle soit à locataire unique ou mutualisée lors de l’inscription de l’application dans Azure et garantir le principe Confiance nulle d’accès avec des privilèges minimum afin que votre application demande uniquement 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é a un compte dans Azure Active Directory (AD)

  • Comptes personnels Microsoft (MSA) pour toute personne disposant d’un compte dans outlook.com, Hotmail, Live, Skype, Xbox, etc.

  • Identités externes dans Azure AD pour les partenaires (utilisateurs en dehors de votre organisation)

  • Azure AD Business to Customer (B2C) qui vous permet de créer une solution qui permettra à vos clients d’apporter leurs autres fournisseurs d’identités.

Une partie requise de l’inscription d’application dans Azure AD 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 locataire, vous, en tant que développeur, spécifiez qui peut utiliser votre application en fonction du type de compte. Lorsqu’un locataire ne vous permet pas d’inscrire votre application dans Azure AD, les administrateurs vous fournissent un moyen de communiquer ces détails à l’aide d’un autre mécanisme.

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

  • Comptes dans cet annuaire organisationnel uniquement (O365 uniquement - Locataire unique)

  • Comptes dans n’importe quel annuaire organisationnel (tout annuaire Azure AD - Multilocataire)

  • Comptes dans n’importe quel annuaire organisationnel (tout annuaire Azure AD - Multilocataire) et comptes Microsoft personnels (par exemple, Skype, Xbox)

  • Comptes Microsoft personnels uniquement

Comptes dans cet annuaire organisationnel uniquement - locataire 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. Il s’agit du choix le plus courant pour les applications métier.

Comptes dans n’importe quel annuaire organisationnel uniquement - multilocataire

Lorsque vous sélectionnez Comptes dans n’importe quel annuaire organisationnel (n’importe quel annuaire Azure AD - Multilocataire), vous autorisez tout utilisateur à partir de n’importe quel annuaire Azure AD à se connecter à votre application mutualisée. Si vous souhaitez autoriser uniquement les utilisateurs à partir de locataires spécifiques, vous filtrez ces utilisateurs dans votre code en vérifiant que la revendication tid dans le 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 locataire d’accueil de l’utilisateur. Pour prendre en charge les utilisateurs invités qui se connectent à votre application mutualisée, vous allez utiliser le point de terminaison de locataire 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 (tout annuaire Azure AD - Multilocataire) et comptes Microsoft personnels (par exemple, Skype, Xbox), vous autorisez un utilisateur à se connecter à votre application avec son identité native à partir d’un locataire Azure AD ou d’un compte consommateur. Le même filtrage de locataire et l’utilisation des points de terminaison s’appliquent à ces applications, car elles s’appliquent aux applications mutualisées comme décrit ci-dessus.

Comptes Microsoft personnels uniquement

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

Applications orientées client

Lorsque vous générez une solution dans le Plateforme d'identités Microsoft qui atteint vos clients, vous ne souhaitez généralement 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 offre Azure AD Business to Customer (B2C).

Azure Active Directory B2C fournit une identité entreprise- client en tant que service. En plus de permettre aux utilisateurs de votre application d’avoir un nom d’utilisateur et un mot de passe uniquement pour votre application, B2C vous permet de prendre en charge les clients avec l’identité sociale que vous leur permettez d’apporter afin qu’ils n’aient pas à mémoriser plus de mots de passe. Par exemple, vous pouvez autoriser les utilisateurs à utiliser leur ID Facebook ou Twitter. Vous pouvez également prendre en charge les clients d’entreprise en fédérant votre annuaire Azure AD B2C à Azure AD de vos clients (ou tout fournisseur d’identité qui prend en charge SAML) à OpenID Connect. Contrairement à une application mutualisée, votre application n’utilise pas l’annuaire d’entreprise du client où il protège ses ressources d’entreprise. B2C permet à vos clients d’accéder à votre service ou à votre fonctionnalité sans accorder à votre application l’accès à leurs ressources d’entreprise.

Ce n’est pas seulement pour le développeur

Pendant que vous, en tant que développeur, définissez dans votre inscription d’application qui vous permettra de vous connecter à votre application, vous n’avez pas le dernier mot sur la question de savoir si un utilisateur spécifique, ou des utilisateurs d’un locataire spécifique, peut se connecter à votre application. Le dernier mot provient de l’utilisateur individuel ou des administrateurs du locataire domestique de l’utilisateur. Les administrateurs de locataires veulent souvent avoir plus de contrôle sur une application que la seule personne autorisée à 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 administrateurs de locataire d’avoir ce contrôle, il existe un deuxième objet dans l’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 locataires 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 d’organisation pour une application multilocataire afin que vous puissiez autoriser les utilisateurs d’annuaire d’organisation. En d’autres termes, vous autorisez un utilisateur à se connecter à votre application avec son identité native à partir d’Azure AD. Un principal de service est automatiquement créé dans le locataire lorsque le premier utilisateur d’un locataire s’authentifie auprès de l’application.

Diagramme illustrant une application mutualisée qui peut autoriser les utilisateurs d’annuaires organisationnels

Il n’existe qu’une seule inscription d’application ou un objet d’application, mais il existe une application d’entreprise ou un principal de service (SP) dans chaque locataire qui permet à l’utilisateur de se connecter à l’application. L’administrateur client peut contrôler le fonctionnement de l’application dans son locataire avec l’application Entreprise pour cette application.

Considérations relatives à l’application mutualisée

Les applications mutualisées 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 illustré dans le diagramme ci-dessous. Dans cet exemple, l’application est inscrite dans le locataire 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.

Diagramme illustrant les applications mutualisées connectent les utilisateurs à partir du locataire d’accueil de l’utilisateur lorsque l’application utilise un point de terminaison commun ou d’organisation

En tant que développeur, il est de votre responsabilité de séparer les informations du locataire. Par exemple, si les données Contoso proviennent de Microsoft Graph, l’utilisateur B de Contoso voit uniquement 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 locataire Adatum, car Microsoft 365 a une véritable séparation des 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 d’organisation, afin que l’utilisateur se connecte en mode natif à son locataire, où que ce locataire soit et qu’il n’y a pas de processus d’invitation requis. Un utilisateur peut simplement s’exécuter et se connecter à votre application, et il fonctionnera après que l’administrateur de l’utilisateur ou du locataire 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, la fonctionnalité Azure AD Business to Business (B2B) permet de le faire. Comme illustré dans le diagramme ci-dessous, les entreprises peuvent inviter des utilisateurs à devenir des utilisateurs invités dans leur locataire. Une fois que l’utilisateur a accepté 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 locataire.

Diagramme illustrant les entreprises qui invitent des utilisateurs invités à leur locataire

Lorsqu’un utilisateur invité doit s’authentifier, il se connecte à son locataire personnel, un compte Microsoft personnel, un compte d’un autre fournisseur d’identité ou avec un code secret à usage unique à l’aide de n’importe quel compte de messagerie. Une fois qu’ils se sont authentifiés auprès de leur fournisseur d’identité, Azure AD du locataire invitant fournit à l’application un jeton qui les identifie en tant qu’utilisateur invité dans le locataire. Cet utilisateur invité peut ensuite accéder aux données du locataire invitant.

En tant que développeur, gardez à l’esprit ces considérations 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 de l’utilisateur invité. Vous ne pouvez pas utiliser les points de terminaison communs, d’organisation ou de consommateurs.

  • L’identité de l’utilisateur invité est différente de l’identité de l’utilisateur dans son locataire domestique ou un autre fournisseur d’identité. Cela signifie que la revendication oid dans le jeton d’un utilisateur invité sera différente de l’oid de la même personne dans son locataire domestique.

Étapes suivantes