Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management (IAM) service and an identity provider (IdP).

Azure AD is the backbone for authentication in Microsoft 365 (Office 365) and also for other cloud based services like thousands of other SaaS applications.

To learn the difference between Azure AD and Active Directory Domain Services, see the following Microsoft article Compare Active Directory to Azure Active Directory.

With Azure AD, you will get several features for your organization. More information about the different features you will find in the following Microsoft article.

Which features work in Azure AD?

One of these features is the Microsoft identity platform which helps developers to build applications where users and customers can sign in to using their Microsoft identities or social accounts, and provide authorized access to their own APIs or Microsoft APIs like Microsoft Graph.

The Microsoft identity platform for developers is an authentication service, open-source libraries, and application management tools

One of the open-source libraries are the Microsoft Authentication Library (MSAL)

Overview of the Microsoft Authentication Library (MSAL)

There are several components that make up the Microsoft identity platform. More about it you can read in the following Microsoft article.

What is the Microsoft identity platform?

Application management portal: A registration and configuration experience in the Azure portal, along with the other Azure management capabilities.

To dig deeper into App registrations and Enterprise application you can also read my following post about OAuth 2.0 and OpenID Connect. OAuth 2.0 is the main authorization framework and the de facto industry standard for online authorization which is used by Azure AD and the reason we need to register our app in Azure.

For this post we are interested in the application management portal component from the Microsoft identity platform regarding App Registrations vs. Enterprise Applications.

You will find both in the Azure portal under Azure AD.

The purposes and differences between both are well documented from Microsoft in the following article.

Application and service principal objects in Azure Active Directory

App Registration vs Enterprise Applications

I will outline here the key points of both modules.

In order to delegate Identity and Access Management functions to Azure AD, an application must be registered with an Azure AD tenant. When you register your application with Azure AD, you are creating an identity configuration for your application that allows it to integrate with Azure AD

When you register an app in the Azure portal, you choose whether it’s a single tenant (only accessible in your tenant) or multi-tenant (accessible in other tenants) and can optionally set a redirect URI (where the access token is sent to).

Registering your application establishes a trust relationship between your app and the Microsoft identity platform. The trust is unidirectional: your app trusts the Microsoft identity platform, and not the other way around.

When you’ve completed the app registration, you have two types of objects created:

  • Application Object
  • Service Principal Object

The Application Object is what you see under App registrations in Azure AD below in the screenshots.

An Azure AD application is defined by its one and only application object, which resides in the Azure AD tenant where the application was registered (known as the application’s “home” tenant). An application object is used as a template or blueprint to create one or more service principal objects

The application object describes three aspects of an application: how the service can issue tokens in order to access the application, resources that the application might need to access, and the actions that the application can take.

Application Object in App registrations

The Service Principal Object is what you see under Enterprise applications in AAD below in the screenshots.

To access resources that are secured by an Azure AD tenant, the entity that requires access must be represented by a security principal.

This requirement is true for both users (user principal) and applications (service principal).

For example an entity that requires access, can be a registered web application in the Azure portal, that wants to access the users profile data in Azure AD, from the user who actually tries to log in to the web application, in order to use this data to manage access and permissions for itself.

Every Application Object (created through the Azure Portal or using the Microsoft Graph APIs, or AzureAD PS Module) would create a corresponding Service Principal Object in Enterprise applications of AAD.

A service principal is a concrete instance created from the application object and inherits certain properties from that application object. A service principal is created in each tenant where the application is used and references the globally unique app object. The service principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access.

Similar to a class in object-oriented programming, the application object has some static properties that are applied to all the created service principals (or application instances).

Service Principal Object in Enterprise applications

The application object is the global representation of your application for use across all tenants, and the service principal is the local representation for use in a specific tenant.

The application object serves as the template from which common and default properties are derived for use in creating corresponding service principal objects. An application object therefore has a 1:1 relationship with the software application, and a 1:many relationship with its corresponding service principal object(s).

A service principal must be created in each tenant where the application is used, enabling it to establish an identity for sign-in and/or access to resources being secured by the tenant.

A single-tenant application has only one service principal (in its home tenant), created and consented for use during application registration. A multi-tenant application also has a service principal created in each tenant where a user from that tenant has consented to its use.

In contrast to a single-tenant application, where you always have both objects, an application object in App registrations and a service principal in Enterprise applications, a multi-tenant application will not create an application object in App registrations for tenants who want to use that app.

An application object is unique and is only created and living in the Azure home tenant from the developer of that app. All other tenants who wants to use this app, only references to this app with a service principal listed in Enterprise applications in their own tenant.

More about that you will find also in the following Microsoft article.

How and why applications are added to Azure AD

In Google’s cloud platform there is something similar in contrast to the app registration and enterprise applications from Azure AD. You will find this in the developer console under APIs & Services.

In my following post you will see how to register an application in Google’s cloud platform and API.


How and why applications are added to Azure AD

Azure AD App Registrations, Enterprise Apps and Service Principals (John Savill)

Application and service principal objects in Azure Active Directory

Quickstart: Register an application with the Microsoft identity platform

What is Azure Active Directory?

Microsoft identity platform documentation

Compare Active Directory to Azure Active Directory

Overview of the Microsoft Authentication Library (MSAL)