What are Azure App Registration, Enterprise Apps, and Service Principals

6 min readDec 16, 2022

I’ve often been asked this question several times, mainly about the relationship between Service Principals and App Objects.

So, let’s start with App Registration and why we need it.

If you are looking for a Microsoft Identity Platform (Azure AD) to provide authentication and authorization for your apps, it must go through the App Registration process. After successful registration, it enables trust between your app and your identity provider, which is Azure AD.

Now, a user who has access to register apps will create an identity or a representation of your app in the Azure Active Directory. This is nothing but an Application Registration process.

After successful registration of your app, you will notice the app is created in 2 places — “App Registrations” and “Enterprise applications”. It created a globally unique identifier Application (client) ID in Application Registration and a local Service Principal Object with the same name in the Enterprise Application.

App Registration vs Enterprise Application

So why do we need a local and a globally unique identifier and what is the relationship between them?

App Registrations

Apps under “App Registrations” represent the actual application object. This is the place where you set the authentication and authorization requirements of your app. You are mainly focused on your application's needs and wants. For instance, under App Registration, you can set:

Define Scope: Which APIs should your app interact with (ex: Microsoft Graph)? What type of API permissions/scope does your app require (ex: User.ReadWrite.All, User.Read)?
Application Permissions or Delegated Permissions: Can your application use its own permissions (app permissions) [OR] signed-in user permissions (delegated) to access Azure resources?
Client Secrets or Certificates: Your app will pass credentials, i.e. either via a client secret or a certificate to Azure AD to prove its identity, and therefore request tokens

As you may notice, in App Registrations, we configured authentication requirements such as client secret/certificates and authorization requirements such as defining scopes/API permissions.

Enterprise Application

For a single-tenant application, an Enterprise App with the same name is automatically created once you register an application. Keep tight, we will discuss Enterprise Apps for multi-tenant applications in the next section.

The configurations that you have set for your app under App Registrations are referenced by your Enterprise Application. Enterprise Apps is all about how your app should behave and work in your ‘local’ tenant. It is up to the administrator of your organization to control the settings of your app which should work within the constraints of your tenant.

Enterprise Apps mainly focuses on:

Consent tracking: When a client or user is trying to access Azure resources under the context of your registered app, it typically goes through an initial consent process. As an administrator for your tenant, you can track and control the consent process. For example, instead of regular users granting consent to an application, because of the sensitive nature of your organization, it may require that only admins can consent to it. Once administrator consent is recorded by Azure AD, your app can request tokens without having to request consent again.
Scope/ API Permission management: Admins can review scope permissions that were set by your app under App Registration. Depending on the nature of your tenant, admins may restrict its scope or may allow users to consent to a subset of permissions rather than the entire set of permissions that your app is requesting for.
Management: Set owners or groups to manage your app, configure SSO, and if required set any additional approval access before granting permissions, etc.

Service Principal

So what are Service Principals? In simple terms, these are nothing but your “Enterprise Applications”. When you open this blade from your portal, you see the list of Service Principals of all your apps.

Service Principal is local to your tenant, whereas your Application/client ID is the global representation of your application and can be used across multiple tenants.

As discussed earlier, once you register an app, Azure automatically creates a local representation of your app in the Enterprise App, which is nothing but your Service Principal object. This Service Principal is referring to your global application object. It inherits certain properties such as scope and permissions from that global application object and you can define what this app can actually do in your tenant, who can access the app, and what resources the app can access.

Relationship b/w App Object and Service Principal

So, in summary, your global Application object is responsible for setting client secrets/certificates and defining scopes and API permissions, while your Service principal object reviews and controls consent tracking, modifies scopes in regulation with your tenant policies, and manages your app authorization in general.

But, what about applications that were registered outside your tenant?

Multitenant apps

In order to create an app that can be used across multiple tenants, you can select the below options depending on whether your app requires personal Microsoft accounts or not.

Let’s walk through the below example:

Let’s assume that you created and registered a multitenant app called demo-app in your home Tenant A. As part of the registration process, it creates a global application object (under App Registration) and a local Service Principal object (under Enterprise Apps).

Tenant B and Tenant C want to consume your demo-app. After providing the valid demo-app application link to these consumers, it will go through the consent process. The scope permissions that were set on demo-app’s definition will be displayed on the consent prompt requesting admin to grant permissions on specific resources. This provides consumer admins with enough information to determine if they can trust the client application or not.

Side Note: The app could be configured/designed to allow consent by users for individual use. If the app is configured to allow admin consent, it is mainly designed with an intent for the entire tenant.

Once the consent is approved, only the Service Principal Object is created in the consumer’s tenant and NOT the application object.

Note: Service Principal is created either upon registration or consent (for multitenant OR SaaS applications)

There will be ONLY one application object which lives in Tenant A. The Service Principal objects created in Tenant B and Tenant C are nothing but a local representation of your globally unique Tenant A’s application object and are referenced via the Application (client) ID.

References

https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals