Understanding Azure App Registrations, Enterprise Applications and Managed Identities
Azure App Registrations and Enterprise Applications can be hard to distinguish. In this article I explain the details and dependencies of each Resource Type.
Introduction
Azure App Registrations are a fundamental component in securing and managing access to applications in Azure Active Directory (now Microsoft Entra ID). They allow applications to authenticate users and services securely using industry-standard authentication protocols such as OAuth 2.0 and OpenID Connect.
If you’re new to Azure, this guide will help you understand App Registrations, their purpose, and how they interact with Azure Enterprise Applications and Managed Identities.
What is an Azure App Registration?
An App Registration in Microsoft Entra ID (formerly Azure Active Directory) is the formal identity definition of your application within your Azure tenant. It acts as the application's digital identity and provides the configuration needed to authenticate and authorize access to resources securely.
With an App Registration, you define:
- which authentication protocols the app supports (e.g., OAuth 2.0, OpenID Connect),
- which redirect URIs are allowed,
- what API permissions (scopes) can request or the roles the app can expose,
- the Client Secrets to authenticate to other App Registrations,
- which optional Claims a returned token should contain.
Essentially, the App Registration is the blueprint of how your app will interact with Microsoft identity services.
What is an Azure Enterprise Application?
An Enterprise Application is the Service Principal instance of an App Registration within a specific Entra ID tenant. It represents the actual application in use in the context of your organization.
When you register a new app or connect to a third-party application (like something from the Azure Marketplace), Azure automatically creates an Enterprise Application in your tenant.
Enterprise Applications allow you to:
- assign users or groups to the app,
- configure access policies, conditional access, and SSO (Single Sign-On),
- audit sign-in logs and application usage,
- and manage app-specific settings like consent and provisioning.
How are App Registrations and Enterprise Applications connected?
In Microsoft Entra ID, App Registrations and Enterprise Applications represent two tightly linked but fundamentally different identity objects. While they share a common origin, their responsibilities diverge sharply in an enterprise context.
The App Registration is the authoritative identity definition. A global construct residing in the home tenant, where the application is initially developed and published. It defines how the application authenticates, what resources it can access, and how it presents itself to identity providers.
In contrast, the Enterprise Application is the tenant-local projection of that app. A Service Principal that operates as the execution context of the application within a specific tenant. It enables runtime policies, user and group assignments, conditional access enforcement, sign-in monitoring, and integration with entitlement management.
This distinction becomes critical in multi-tenant scenarios, delegated permission models, and least-privilege enforcement across federated identity landscapes.
| App Registration | Enterprise Application (Service Principal) |
|---|---|
| Application object a global definition stored in the home tenant | Service Principal object a local instantiation of the application in a specific Entra ID tenant |
| Defines identity metadata: redirect URIs, app secrets/certs, roles, API scopes, token configuration, supported flows | Governs how and if the app can sign in, who can access it, and how permissions are enforced |
| Exists once per application, in a single tenant (home directory) | Exists once per tenant, but can appear in many tenants. Has a 1:n mapping from App Registration |
| Cannot be assigned to users or groups directly | Used for role assignments, group/user access, Conditional Access, and entitlement management |
| Supports multi-tenant publishing: third-party tenants get their own Enterprise App upon consent | Represents the application within Enterprise Applications of each tenant |
| Used by developers, devops, and app architects to define how the app behaves during authentication and authorization | Used by security teams, identity admins, and IT operators to control how the app is used in production, within the local tenant |
Terraform resource: azuread_application | Terraform resource: azuread_service_principal |
You can’t have an Enterprise Application without an App Registration. The App Registration is the source definition, while the Enterprise Application is what actually runs in your tenant and can be assigned, monitored, and managed.
Impact on System- and User-assigned Managed Identities
Whether you're deploying your application on App Services, Azure Functions, AKS workloads, or Virtual Machines, your compute resources often need to authenticate securely, integrate with other services, or expose their own APIs. All of these scenarios require a backing identity, and that identity is represented in Entra ID using Managed Identities.
Many Azure compute services (App Services, VMs, Functions, etc.) support Managed Identities (system-assigned or user-assigned). Behind the scenes, these identities are Enterprise Applications (Service Principals).
When you choose system-assigned Managed Identities you do not need to create a specific App Registration, because Azure is handling this for you. But if you decide to use an user-assigned Managed Identity, you need to create an App Registration.
While both types create an Enterprise Application (Service Principal) in Microsoft Entra ID, an App Registration is only explicitly created for user-assigned identities. In contrast, system-assigned identities are fully managed by Azure and do not expose an App Registration to the tenant.
The following table summarizes the key differences between user-assigned and system-assigned Managed Identities.
| System-Assigned Managed Identity | User-Assigned Managed Identity | |
|---|---|---|
| Creation | Automatically created when the resource is provisioned. | Created manually and assigned to one or more resources. |
| Lifecycle | Tied to the lifecycle of the Azure resource. | Independent of any resource. |
| Entra ID Object(s) | Only a Service Principal (Enterprise App). | Both an App Registration and a Service Principal. |
| Visibility in Entra ID | Visible in Enterprise Applications. | Visible in both App Registrations and Enterprise Applications. |
| Resource Scope | One unique identity per resource. | Reusable across multiple resources. |
| Management Responsibility | Fully managed by Azure. | Fully managed by the user. |
| Assignment to Resources | Implicitly bound to the creating resource. | Explicitly assigned to resources manually. |
| Naming | Name is autogenerated based on the resource. | Name is custom-defined by the user. |
| Usage Scenario | Use when identity is only needed by one resource. | Use when identity is shared or needs independent lifecycle. |
| Auditing & Sign-in Logs | Logs show Service Principal activity only. | Logs show App Registration and SP activity. |
The overall reason to leverage the use of Managed Identities is the ability to grant specific Azure roles and permissions following the principle of least privilege. This ensures that applications or services only have access to the resources they truly need reducing the attack surface and improving overall security posture.
In this context, Azure Role-Based Access Control (RBAC) plays a crucial role. RBAC allows fine-grained access management to Azure resources by assigning roles to users, groups, and service principals (like managed identities). By combining Managed Identities with RBAC, you can enforce clear boundaries on what a service can do, ensuring compliance, traceability, and least privilege access without the need to manage secrets or credentials manually.
Conclusion
Understanding Azure App Registrations is crucial for securing applications in Azure. By leveraging Terraform, organizations can automate the provisioning of secure authentication mechanisms, ensuring scalability, high performance, and minimal security risks. Implementing best practices like managed identity and API permission controls further enhances security while reducing operational overhead.
Helpful Links for Further Research
- Difference Between App Registrations and Enterprise Applications
- https://medium.com/@shoaib.alam/part-4-oauth-2-0-pkce-flow-with-azure-ad-cc225c0ed9f6
- https://www.emilyvanputten.com/the-difference-between-azuread-app-registrations-and-enterprise-applications-explained/
- https://learn.microsoft.com/en-us/answers/questions/270680/app-registration-vs-enterprise-applications
- App Registrations
- Real-World Use-Cases: