The Differences Between App Registrations, Enterprise Applications, and Service Principals in Azure AD
In 2019 I answered a question on Stack Overflow about the difference between App Registrations and Enterprise Applications in Azure Active Directory. Two years later I still see questions about the differences between these two terms, as well as questions about how the term “Service Principal” relates to each. The purpose of this blog post is to define these three terms and clarify how they differ from each other.
App Registrations
An App Registration is a way of reserving an application in Azure AD. The registration enables Azure to communicate with the application and pass tokens to it. When you have an application that you are developing and want to integrate it with Azure, you must register your application in the App Registrations experience. There you will configure your Redirect URI (the address where your users will be sent immediately after they have logged in and authenticated), logout URL (the address where your users will be sent after they have logged out), API access if needed, and custom app roles for assigning permission to users or apps.
When you register your application, Azure AD assigns a unique Application ID to it and allows you to add certain capabilities such as credentials, permissions/roles, and sign-ons. The default settings allow only users from the tenant under which your app is registered to sign into your application, but that can be changed to restrict access to particular users.
Enterprise Applications
The Enterprise Applications blade might be confused with App Registrations because the Enterprise Application blade contains the list of your Service Principals (which get created when you register your applications). However, the term Enterprise App generally refers to applications published by other companies in the Azure Active Directory gallery that can be used within your organization. For example, if you want to integrate an application such as Facebook or Microsoft Teams and manage SSO within your organization, you can integrate it from the Enterprise Applications dropdown in the applications blade. Your own applications (which you registered) will also be represented in the Enterprise Applications blade as Service Principals, which are instantiations of your applications in the tenant.
Service Principal
A Service Principal and an Enterprise Application are actually the same thing, but the terms can have slightly different connotations. While the term “Enterprise App” is often used to describe application integrations (i.e. G Suite, Facebook), Service Principal is used more broadly to describe the security principal for the application that is used to grant permissions or consent to resources. The Service Principal object is the place where the application’s instance in the tenant is recorded and managed. When you register an application, the portal creates both an application object and a Service Principal object that points to the application object.
The Application IDs for both resources are the same because they point to the same application, but the Object IDs are different because they have slightly different purposes.
One way to think of it is that there is a single process of registering an application, and that process creates two things:
- The App Registration itself (or application object)— This is the actual application object where you configure application settings.
- The Enterprise Application (or Service Principal object) — This is a representation (or instantiation) of the application within a directory. It acquires the settings from the application object and is used to grant consent to resources.
This gets confusing because a user can grant consent from both the Enterprise Applications (service principal) blade and the App Registrations experience in the Azure Portal, but this is only the case for the sake of convenience. The consent is granted from the service principal (enterprise application), but in the UI can be administered from the App Registration so that the user does not need to navigate to Enterprise Apps to grant consent.
One notable difference is that an App Registration can reside in any directory, but an Enterprise application (Service Principal) must be present in the same directory for every tenant where the application is running. (See Configure an OpenID/OAuth application from the Azure AD app gallery.)
To sum it up, the Azure Portal creates one place for recording developer-owned configurations (corresponding to the application object in the App Registration), and another place where the application’s instance in a tenant is managed (the ServicePrincipal object in the Enterprise Applications blade). Though the term “Enterprise Application” generally refers to applications published by other companies in the Azure Active Directory gallery, it also includes the list of Service Principals that you create in the Azure tenant itself. In theory, all of these terms could be combined into one “Applications” experience.
References:
https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app
