When working with Azure Active Directory (Azure AD), I often come across terms like App Registrations, Service Principals, and Enterprise Applications — and they can easily get confusing. In this post, I’ll break down what each one means, how they relate to each other, and when you’d typically use them.
📌 What is an app registration?
An App Registration in Azure AD is essentially the identity definition for an application I want to integrate with Entra ID. Let’s say I have a .NET application running as function app and I want to register it within the Azure. To do this, I register the application in Microsoft Entra ID, which in turn assigns it its own unique identity within the directory:
Another way I like think of it is as the blueprint or template of my application within my Entra ID tenant. The actual application runs outside of Entra ID — whether it’s a web app, API, or Function App — but its identity and related permissions are defined and managed within Entra ID.
.NET app:
As an example, let’s assume this app is periodically retrieves information about Entra ID users – such as their names, role assignments, groups, etc. It then processes and analyzes this data to generate reports, such as:
- List of users with privileged roles (e.g. Global Admin, User Access Administrator)
- Inactive users in security-critical groups
- Users assigned roles they shouldn’t have (role drift detection)
- Group membership anomalies (e.g. users in unexpected admin groups)
As you may have already noticed, the app needs certain permissions to retrieve mentioned information. This is precisely where App Registrations come into play – we register the app in Entra ID and assign it necessary permissions. Also, to use the application (or it’s API), the Entra ID users need the permissions as well – in this example, we might want to assign the permissions to admins, so they can review the reports.
Therefore in this scenario, the permissions work both ways:
- App needs permissions to read Entra ID information
- Users need permissions to access the App (or it’s API)
How to create app registration
In this section, I show how to register an app in Entra ID.
- Head to your Entra ID -> App registrations
- Click New Registration
- Fill out the parameters for app:
Next we need to fill out the following parameters:
- Name – name of the app
- Supported account types – this essentially tells us who can access our application. In this scenario, we use the app to perform our internal Entra ID analysis, so we select only this directory – Single tenant. But if other organizations wanted to use the app as well, we would choose multitenant.
- Redirect URI – the location where the Microsoft Entra authentication server sends the user once they have successfully authorized. In this scenario we assume that our app is in the form of web app, therefore we send the users to it’s url.
- Lastly click on Register
After you register the app, it’s identity is created and you are presented with following screen:
As shown in the image, the application has been successfully registered. It comes with three unique identifiers and one Redirect URI, which I defined during the registration process.
The three identifiers are:
- 1. Application (client) ID
- What it is: A globally unique identifier assigned to your app when it is registered in Entra ID.
- Purpose: Used by the app to authenticate itself when making API requests to Microsoft Graph or other services in Azure. It identifies the app during the authentication process using OAUTH2.
- 2. Object ID
- What it is: A unique identifier for the specific instance of the app object in Entra ID.
- Purpose: This ID is used to reference the app’s object within the directory. It is used for managing and assigning app-related permissions such as API permissions.
- 3. Directory (tenant) ID
- What it is: A unique identifier for the Entra ID tenant (the entire organization or directory) where the app is registered.
- Purpose: This ID is used to uniquely identify the tenant, which is essential for distinguishing between different Entra ID directories when you’re working with multi-tenant applications.
The main distinction between Application (client) ID and Object ID is that the former is used to authenticate the app to Entra ID and to subsequently make various requests using Graph API or other services – so it is used purely for authentication as well as Azure services. On the other hand, Object ID is the app’s reference in Entra ID – you can think of it as a local instance of app within Entra. For example, it is used to assign API permissions for the application.
📌 What is a service principal and an enterprise application?
Every time you create app registration, it is also created in the Enterprise Applications section of Entra ID:
The enterprise application is also called a service principal – just a different name. But what is service principal ?
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. When the app registration is created, the service principal is created also and it is referencing the app registration via it’s Application ID.
When we click on already created service principal (enterprise app), notice the Application (client) ID parameter (for security reasons I blurred large portion of Application ID as well as Object ID):
The application ID starts as 6020. Now go back to your app registration and review it’s application ID:
As you see from the picture, both the service principal and the app registration are connected via the application ID. So there is 1:1 relationship in Entra ID when it comes to app registration and it’s service principal – every time the app registration is created, it’s service principal is created also – and it is listed under enterprise apps in Entra ID:
🔍 Key detail I remind people of:
An App Registration exists at the directory level, but to assign permissions or roles, you use a Service Principal — which acts as the actual security identity and is listed under the ‘Enterprise Apps’ section in Entra ID.
🔄 Authentication flow for users enumeration
The following picture explains the app authentication to Entra ID:
- Step 1:
The app (function-app-1) needs to authenticate to Entra ID and uses its App Registration (Client ID + secret/certificate) to start the OAuth2 flow. - Step 2:
Entra ID validates the app’s credentials through the OAuth2 client credentials grant and confirms its identity. - Step 3:
The app wants to enumerate (read) users from Entra ID — typically via Microsoft Graph API. - Step 4:
Entra ID checks the app’s role assignments and directory permissions attached to its Service Principal in the tenant to verify if it’s authorized to perform that action. - Step 5:
If permissions are valid, Entra ID issues an OAuth2 access token containing claims and role information for the app. - Step 6:
The app sends an API request (e.g.GET /users) to Entra ID (via Microsoft Graph) using the access token. - Step 7:
Entra ID validates the token and permissions, then returns the user data (like names, roles, groups) to the app in the API response.
📝Final thoughts
Working with App Registrations, Service Principals, and Enterprise Applications in Entra ID can feel a little abstract at first — but once I started seeing how these pieces interact in real authentication and authorization flows, it became much clearer.
To recap:
- App Registrations are the identity blueprints for applications in my tenant.
- Service Principals (Enterprise Applications) are the actual instances of those apps within the tenant, responsible for enforcing permissions and access policies.
- These two objects are linked via the Application (client) ID.
When my app needs to interact with Entra ID — like retrieving user data through Microsoft Graph — it uses its App Registration to authenticate and its Service Principal to enforce permissions. By carefully managing both, I can securely integrate apps with my Azure environment while maintaining control over what data they access and who can use them.
Understanding this relationship is fundamental for anyone designing secure, scalable identity-based applications in Azure.
If you’ve made it this far — great work. You now have a solid grasp of how identity objects in Entra ID relate to each other and how they fit into OAuth2-based authentication flows.
