The difference between AzureAD App Registrations and Enterprise Applications explained

The lack of clarity regarding app registrations and enterprise applications is regularly discussed. Both terms are used interchangeably by people and to make it even more unclear, different terminology is used within the Azure portal and for example PowerShell or the API.

In this article I will briefly explain what both are and how they relate to each other. (no, app registrations and enterprise applications are not the same. But there is a relationship between the two). So that the picture below becomes also clear to you.

Definitions

Note: To avoid misunderstandings, this article uses the terms as they apply within the Azure portal. The counterparts from PowerShell are placed behind them between “()”.

App Registration (Application)

An App Registration (Application) is an object that is included in Azure AD and describes the application. In fact, it is the definition of the application in which various elements are included, eg.

  • Name, logo, and publisher
  • Redirect URIs
  • Secrets (symmetric and/or asymmetric keys used to authenticate the application)
  • API dependencies (OAuth)
  • Published APIs/resources/scopes (OAuth)
  • App roles (RBAC)
  • SSO metadata and configuration
  • User provisioning metadata and configuration
  • Proxy metadata and configuration

An App Registration (application) can be used for single- or multi-tenant purposes (depending on the use-case). However it only exists in 1 single directory, also called it’s home directory.

Enterprise Application (Service Principal)

An App Registration (Application) on its own cannot really do anything. After all, it is only a definition of the application. This is where the Enterprise Application (Service Principal) comes into the picture. Perhaps the “Service Principal” naming gives some more clarity, but this is an identity within a directory, which can only be given rights within the same directory. The Enterprise Application (Service Principal) object is the instance of an app registration (application).

If you have read the above carefully, you will see that the Enterprise Application (Service Principal) can only be given rights within the directory of which it itself is part. In contrast to the App Registration (Application), an Enterprise application (Service Principal) will have to be present in the same directory for every tenant where the application is active.

Relation

A workload has one App Registration (Application) object in its home directory that is referenced by one or more Enterprise Applications (Service Principals) in each of the directories where it operates, including the home directory of the App Registration (Application). The reference is made by means of the ‘Application ID’ property of the Enterprise Application (Service Principal), which refers to the application id of the App Registration (Application).

Local and Global or Global and Local?

Finally, the explanation of App Registrations (Applications) and Enterprise Applications (Service Principals) often refers to local and global. But there are different views on this, with regards to which object is local or global. The App Registration (Application) or the Enterprise Application (Service Principal). I will try to explain where both views come from.

  1. If you have read the explanation of both types of objects in this article, you can say on the one hand that an App registration (Application) is located within 1 (local) directory and the Enterprise Application (Service Principal) here is a (global) instance of because it is located within 1 or more directories. The essence is that this refers to 1 (local) directory VS multiple (global) directories.
  2. On the other hand, the App registration (Application) is the (global) object, which is referenced from the (local) Enterprise Application (Service Principal) instances located in the directories. The essence behind this is that there is a (local) object within each directory that refers to a (global) object within another directory (which can be the same directory in some cases).

It just depends on which side you look at it, but now you at least understand what is meant by this.

See also

Azure AD role-assignable groups

It has recently become possible with Azure AD role-assignable groups (in addition to assigning an Azure AD role to a user) to be able to assign roles to an Azure AD group. This allows you to keep an overview because … Read More
Read More

Privileged access groups

With privileged access groups, an extra privileged identity management (PIM) functionality has recently been added. It allows you to make individuals or groups eligible for group membership and ownership, as opposed to permanent allocations.Because you can link different privileged identity … Read More
Read More