Identity and account types for single- and multi-tenant apps

This article will explain how you, as a developer, can choose if your app allows only users from your Azure Active Directory (Azure AD) tenant, any Azure AD tenant, or users with personal Microsoft accounts. You can configure your app to be either single tenant or multitenant during app registration in Azure. Ensure the Zero Trust principle of least privilege access so that your app only requests permissions it needs.

The Microsoft identity platform provides support for specific identity types:

  • Work or school accounts when the entity has an account in an Azure Active Directory (AD)
  • Microsoft personal accounts (MSA) for anyone who has account in, Hotmail, Live, Skype, Xbox, etc.
  • External identities in Azure AD for partners (users outside of your organization)
  • Azure AD Business to Customer (B2C) that allows you to create a solution that will let your customers bring in their other identity providers. Applications that use Azure AD B2C or are subscribed to Microsoft Dynamics 365 Fraud Protection with Azure Active Directory B2C can assess potentially fraudulent activity following attempts to create new accounts or sign in to the client's ecosystem.

A required part of application registration in Azure AD is your selection of supported account types. While IT Pros in administrator roles decide who can consent to apps in their tenant, you, as a developer, specify who can use your app based on account type. When a tenant doesn't allow you to register your application in Azure AD, administrators will provide you with a way to communicate those details to them through another mechanism.

You'll choose from the following supported account type options when registering your 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

Accounts in this organizational directory only - single tenant

When you select Accounts in this organizational directory only (O365 only - Single tenant), you allow only users and guests from the tenant where the developer has registered their app. This option is the most common for Line of Business (LOB) applications.

Accounts in any organizational directory only - multitenant

When you select Accounts in any organizational directory (Any Azure AD directory - Multitenant), you allow any user from any Azure AD directory to sign in to your multi-tenant application. If you want to only allow users from specific tenants, you'll filter these users in your code by checking that the tid claim in the id_token is on your allowed list of tenants. Your application can use the organizations endpoint or the common endpoint to sign in users in the user's home tenant. To support guest users signing in to your multitenant app, you'll use the specific tenant endpoint for the tenant where the user is a guest to sign in the user.

Accounts in any organizational account and personal Microsoft accounts

When you select Accounts in any organizational account and personal Microsoft accounts (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox), you allow a user to sign in to your application with their native identity from any Azure AD tenant or consumer account. The same tenant filtering and endpoint usage apply to these apps as they do to multitenant apps as described above.

Personal Microsoft accounts only

When you select Personal Microsoft accounts only, you allow only users with consumer accounts to use your app.

Customer facing applications

When you build a solution in the Microsoft identity platform that reaches out to your customers, usually you don't want to use your corporate directory. Instead, you want the customers to be in a separate directory so that they can't access any of your company's corporate resources. To fulfill this need, Microsoft offers Azure AD Business to Customer (B2C).

Azure AD B2C provides business-to-customer identity as a service. You can allow users to have a username and password just for your app. B2C supports customers with social identities to reduce passwords. You can support enterprise customers by federating your Azure AD B2C directory to your customers' Azure AD (or any identity provider that supports SAML) to OpenID Connect. Unlike a multitenant app, your app doesn't use the customer's corporate directory where they're protecting their corporate assets. Your customers can access your service or capability without granting your app access to their corporate resources.

It's not just up to the developer

While you define in your application registration who can sign in to your app, the final say comes from the individual user or the admins of the user's home tenant. Tenant admins often want to have more control over an app than just who can sign in. For example, they may want to apply a Conditional Access policy to the app or control which group they allow to use the application. To enable tenant admins to have this control, there's a second object in the Microsoft identity platform: the Enterprise app. Enterprise apps are also known as Service Principals.

For apps with users in other tenants or other consumer accounts

As shown in the diagram below using an example of two tenants (for the fictitious organizations, Adatum and Contoso), supported account types include the Accounts in any organizational directory option for a multi-tenant application so that you can allow organizational directory users. In other words, you'll allow a user to sign in to your application with their native identity from any Azure AD. A Service Principal is automatically created in the tenant when first user from a tenant authenticates to the app.

Diagram shows how a multitenant application can allow organizational directory users.

There's only one application registration or application object. However, an Enterprise app, or Service Principal (SP), in every tenant allows users to sign in to the app. The tenant admin can control how the app works in their tenant.

Multitenant app considerations

Multitenant apps sign in users from the user's home tenant when the app uses the common or organization endpoint. The app has one app registration as shown in the diagram below. In this example, the application is registered in the Adatum tenant. User A from Adatum and User B from Contoso can both sign into the app with the expectation User A from Adatum will access Adatum data and that User B from Contoso will access Contoso data.

Diagram shows how multitenant apps sign in users from user's home tenant when app uses common or organization endpoint.

As a developer, it's your responsibility to keep tenant information separate. For example, if the Contoso data is from Microsoft Graph, the User B from Contoso will only see Contoso's Microsoft Graph data. There's no possibility for User B from Contoso to access Microsoft Graph data in the Adatum tenant because Microsoft 365 has true data separation.

In the above diagram, User B from Contoso can sign in to the application and they can access Contoso data in your application. Your application can use our common (or organization) endpoints so the user signs in natively to their tenant, requiring no invitation process. A user can run and sign in to your application and it will work after the user or tenant admin grants consent.

Collaboration with external users

When enterprises want to enable users who aren't members of the enterprise to access data from the enterprise, they use the Azure AD Business to Business (B2B) feature. As illustrated in the diagram below, enterprises can invite users to become guest users in their tenant. After the user accepts the invitation, they can access data that the inviting tenant has protected. The user doesn't create a separate credential in the tenant.

Diagram shows how enterprises invite guest users to their tenant.

Guest users authenticate by signing in to their home tenant, personal Microsoft Account, or other IDP account. Guests can also authenticate with a one-time passcode using any email. After guests authenticate, the inviting tenant's Azure AD provides a token for access to inviting tenant's data.

As a developer, keep these considerations in mind when your application supports guest users:

  • You must use a tenant specific endpoint when signing in the guest user. You can't use the common, organization, or consumer endpoints.
  • The guest user identity is different from the user's identity in their home tenant or other IDP. The oid claim in the token for a guest user will be different from the same individual's oid in their home tenant.

Next steps