Establish applications in the Microsoft Entra ID ecosystem

  • Article

When building applications on Microsoft Entra ID, you first establish an identity for an application. An app needs an identity in Microsoft Entra ID to request tokens. An Application Programming Interface (API) needs an identity in Microsoft Entra ID to have tokens issued for apps to access resources.

In this article, learn how to register apps in a Microsoft Entra ID tenant in the Microsoft Entra admin center, or with the Microsoft Graph API. It's the second in a series of articles on how independent software developers (ISVs) can build and optimize their applications for Microsoft Entra ID. In this series, you can learn more about these topics:

Register applications

Developers can register applications as multitenant apps and single-tenant apps. For ISVs, we recommend multitenant apps. A multitenant app has a single app registration that an ISV completely controls and registers in their tenant. Learn how you can create a Microsoft Entra ID tenant to register your app.

To provide solutions to any customer running Microsoft Entra ID and have a seamless experience for onboarding into the customer's Microsoft Entra ID tenant, go to Microsoft Entra admin center, App registrations, Register an application. On this new app registration, select Supported account types, Accounts in any organizational directory (Any Microsoft Entra ID tenant--Multitenant).

Screenshot of application configuration options in the Microsoft Entra admin center.

Onboarding a multitenant app to an external tenant can be as simple as running an app and having a user sign into the app. When the tenant allows user consent (users can sign in to apps without an admin previously approving an app), onboarding an app only requires that a user signs into the app. This Identity workshop for Developers (time code 1:05:20 to 1:08:00) shows an app being onboarded to a tenant as a user signs into an app.

When you register an app in a Microsoft Entra ID tenant, it receives an Application ID (App ID) that is also known as the client ID for an app. It is like a userid for a user in that it uniquely identifies an app. The App ID is globally unique across the Microsoft Entra ID cloud and immutable. All interactions between an app and Microsoft Entra ID include the App ID.

In addition to the App ID, an app registration contains information about the app that the app developers know or need to know. For example, an app developer needs to know the App ID to interact with Microsoft Entra ID. The developer knows the application type that they're building (web app, native app, single page app, mobile app, or desktop app). Application types have required attributes.

For example, a required application attribute is a Redirect Uniform Resource Identifier (URI). The attribute tells Microsoft Entra ID the web address, or native app address, to send to a user after authentication or authorization. The developer knows the Redirect URIs for an application, based on the app type and where the app runs.

An app's manifest (that you access from the Microsoft Entra admin center or with a Microsoft Graph API) stores the many application attributes. Reference Understanding the Microsoft Entra app manifest to learn about app attributes and their allowed values.

Reference Code samples for Microsoft identity platform authentication and authorization to discover recommended settings for apps that you're developing. Find an application sample that is like the app you're building and read its documentation. Samples detail required app registration settings by app type. For example, if you’re building an API in Node.js, you can find samples that lead you to these registration instructions.

An app registration communicates what a developer knows. In each tenant from which users can authenticate to your multitenant app, tenant admins configure how applications run in their tenant. For example, a tenant admin can set a Conditional Access policy that limits an app to specific network locations. Also, there can be a Conditional Access policy to require multifactor authentication (MFA) for a user to access an app, or app settings that allow specific users, or groups, to use an app.

To enable such limitations, tenant admins need control points for apps in their tenant. Microsoft Entra ID automatically creates an Enterprise Application in each tenant in which a user authenticates an app. In the Microsoft Entra admin center, they're called Enterprise Applications, but the objects are service principals. Learn more about Apps and service principals in Microsoft Entra ID.

After a user authenticates an app, Microsoft Entra ID creates a service principal in the tenant from which the user authenticated. Tenant admins can use the service principal object in Microsoft Graph (or in Microsoft Entra admin center, Enterprise Applications) to configure how an app can work in the tenant.

Service principals aren't copies of an app registration even though they have many of the same attributes. Instead, a service principal links to its app registration. You can view updates to app registrations in linked Enterprise Applications. For multitenant apps, the customer doesn't have access to app registrations that stay in the ISV's tenant. However, an application can access its service principal using Microsoft Graph even when that service principal is in a different tenant. Thus, an app can access attributes about the Enterprise Application (for example, whether it requires user assignment to an app, or the users assigned to a role in the app).

While we recommend multitenant apps for app registration for ISVs, a single tenant app is another option for registering apps. Instead of a single app registration in the ISV's tenant where the ISV completely controls the registration, you can ask your customers to register your app in their tenant for your app. After the customer completes registration, they configure your app instance with the details of their app registration. We recommend this single tenant app approach primarily for Line of Business applications developed for specific enterprises.

Because of the overhead to have customers register and configure your application, we don't recommend single tenant apps for ISVs. However, there are scenarios for which a multitenant app isn't possible for your app.

If your app uses Security Assertion Markup Language 2.0 (SAML), instead of OpenID Connect (OIDC) or OAuth 2.0, it follows a single tenant app registration model. For SAML apps, the order of creation of service principals and app registration is the opposite of an OIDC or OAuth 2.0 app, at least for the admin who adds the SAML app to the tenant. Instead of registering an app and having Microsoft Entra ID automatically create the service principal, admins start by creating an Enterprise app. Microsoft Entra ID automatically creates the app registration. The Microsoft Entra ID app gallery, described in the Publishing applications section, eases the SAML app creation process for admins.

Limitations on Redirect Uniform Resource Identifiers (URIs) can prevent an ISV from creating a multitenant app. An app can have at most 256 Redirect URIs, without wildcards. If your application requires a unique Redirect URI for each customer, and there are more than 256 customers requiring a unique instance, you might not be able to create a multitenant app. You can't use wildcards (*) in Microsoft Entra ID Redirect URIs for security reasons. One option is to have a single Redirect URI for your central service (if a central service is possible). The central Redirect URI would validate the token and then redirect the user to their customer specific endpoint.

Publish applications

When users initially authenticate your app, or authorize an app to access a resource for the user, they decide if they trust your app. Admins can make similar decisions for all users in their tenant. Admins can decide if a user signs in to an app and if an app accesses specific resources.

The following app publication methods can help ISVs to present their apps as deserving users' and admins' trust.

  • Publish your app from a verified domain. The publisher domain informs users and admins which locations receive their information. Publishing from a verified publisher domain shows that an app's registered tenant has control of the domain listed as an app's publisher.
  • Publish your app with publisher verification. Having a verified publisher domain is prerequisite to publisher verification, which goes beyond simply showing that an app publisher has control over a domain. Publisher verification shows that Microsoft verified the entity behind the domain and tenant as authentic. Users who aren't admins often don't trust multitenant apps from unverified publishers. Admins can configure tenants so that apps that aren't from verified publishers always require admin consent. Publisher verification is primarily for ISVs who build multitenant apps on OAuth 2.0 and OIDC. Verified publishers are members of the Microsoft Cloud Partner Program. Publisher verification doesn't impact single tenant apps such as those using SAML or Line of Business apps.
  • Participate in the Microsoft 365 App Compliance Program. Using a verified domain shows that you have control over your domain. Publisher verification shows that Microsoft verified your organization as authentic. Listing your app in the Microsoft Entra ID app gallery shows that your app works with Microsoft Entra ID for easy onboarding. The Microsoft 365 Compliance Program lets you inform your customers about your app's security and compliance by Publisher Attestation, Microsoft 365 Certification, or with the App Compliance Automation Tool (ACAT) in Azure. It shows how your application protects resources that the customer authorizes your app to access.

Next steps

  • Microsoft Entra ID for Independent Software Developers describes how to use this cloud-based identity and access management service to enable employees to access resources with your application.
  • Authenticate applications and users describes how applications use Microsoft Entra ID to authenticate users and applications.
  • Authorize applications, resources, and workloads discusses authorization when an individual human interacts with and directs an application, when APIs act on behalf of a user, and when applications or services work independently.
  • Customize tokens helps you to build security into applications with ID tokens and access tokens from Microsoft Entra ID. It describes the information that you can receive in Microsoft Entra ID tokens and how you can customize them.