Azure AD App Registration, Enterprise App, and Service Principal
![](https://devopswarm.com/wp-content/uploads/2023/03/MicrosoftTeams-image-11.jpg)
Most of the users often get confused with the terms App Registration, Enterprise App, and Service Principals and often use these terms interchangeably. However, each of these has a different purpose based on the usage and behavior of the app in Azure AD. In this blog, we will discuss App Registration, Enterprise Apps, and Service Principals.
Azure App registration:
The Application Registration is reserving your applications in the Azure AD tenant (Developer’s point of view when they develop LOB applications integrated with Azure AD authentication) and when you register an application, an application object gets created in the tenant. The application object is the global representation of the application within/across the tenants which has properties like API permissions, client secrets, branding, logo, etc. The purpose of the app registration in Azure AD is to delegate the identity and access management functionality to your application.
![](https://devopswarm.com/wp-content/uploads/2023/03/Screenshot-2023-03-30-at-9.35.30-PM-1024x667.png)
Whenever an application gets registered, a service principal object also gets created which can be seen in Enterprise Applications. Now, here in this case, the service principal object is the local representation of your application in your tenant and now you define who can access that application and what the application can do.
The application object describes the following aspects of the application such as:
- How the service can issue tokens
- The resources that the application might need to access
- The actions that the application take
Enterprise Applications:
Enterprise applications are the ones published by various vendors like Facebook, and Google for them to use with single sign-on with Azure AD authentication. The application can be an app developed by your developers and published within your tenant as well. These applications are shown in Enterprise Applications Tab in Azure Active Directory. The Service principal object is what gets created when you choose the published app in your tenant. The service principal object defines what the app can do for the specific tenant, who can access the app, and what resources (secured by the tenant) the app can access. You assign the apps to users and groups and also you can define the scope and consent to the apps.
![](https://devopswarm.com/wp-content/uploads/2023/03/Screenshot-2023-03-30-at-9.35.42-PM-1024x597.png)
When you register the app, a service principal object also gets created along with the application object. The service principal object inherits some properties from the application object.
Scenario: To provide seamless automation of resource creation in Azure, you start creating the app registration in the App registration tab in Azure AD and generate client secrets. If you observe, a service principal object also gets created with the same name and client id. To create the resources, you provide the role assignments to the service principal which represents the registered application. Since you defined the scope using the service principal object, now the actual application that uses client secrets will be able to create resources on your Azure subscription which is secured by your tenant.
![](https://devopswarm.com/wp-content/uploads/2023/03/Screenshot-2023-03-30-at-9.55.04-PM-1024x475.png)
Then what is managed identity:
Managed identity is one type of service principal object where you don’t need to manage any credentials, unlike app registrations. When a managed identity is created, a service principal object is created, and you add a scope and define what it can do. It provides the identity for your application to use when connecting to the resources that support Azure AD authentication.
Scenario: Let’s say that you are developing a node application that creates resources in Azure Subscription, and you deploy the app to an Azure Virtual Machine. Now, you can enable the managed identity to your Virtual machine which creates a service principal object, and you add a scope to the object to create resources in the subscription. Now, your application will be able to create resources using the managed identity scope. This way, you can avoid injecting the credentials into the application.
![](https://devopswarm.com/wp-content/uploads/2023/03/MicrosoftTeams-image-10.jpg)
Key points to know:
- One app registration represents on software application
- One app registration (Global app) can have many service principals (in each specific tenant)
- Enterprise Apps ~= Service Principals
- App registration has the client credential property, service principal simply inherits those properties.
- When you add the app to a subscription, you actually add a service principal object.
- The service principal when gets created with app registration will have the same application/client id, and name but different object ids.