When working with Azure Active Directory (Azure AD), you’ll often encounter four related but distinct concepts: App Registrations, Service Principals, Enterprise Applications, and Managed Identities. These terms are often used interchangeably, but they serve different purposes. Let’s break it down.
-
What it is: A blueprint or global definition of an application.
-
Where it lives: Always inside a tenant (also called a directory). The tenant that owns the registration is called the “home tenant.”
-
What it defines:
- Application (client) ID
- Redirect URIs
- Certificates and secrets
- API permissions the app can request
-
Analogy: Think of it as the class definition for an application.
-
What it is: The identity of the app inside a specific tenant.
-
How it’s created: When an app is used or consented to in a tenant, a service principal is instantiated.
-
What it defines: Tenant-specific details like:
- Which users/groups are assigned
- What roles are granted
- Conditional Access policies
-
Analogy: If App Registration is a class, a Service Principal is an instance of that class in a given tenant.
-
What it is: The representation of the Service Principal in the Azure Portal.
-
Where to find it: Azure AD → Enterprise Applications.
-
What it’s used for:
- Assign users and groups
- Configure single sign-on (SSO)
- Apply conditional access policies
- Review sign-in logs and usage
- Service Principal = the actual identity/security principal used for authentication and authorization.
- Enterprise Application = the friendly admin-facing management surface for that service principal.
- They are not separate objects — the Enterprise App is simply the portal/UI view of the SP.
Example Flow:
- You create an App Registration in Tenant A.
- A user in Tenant B consents to it.
- Azure AD creates a Service Principal in Tenant B.
- Tenant B’s admins manage it under Enterprise Applications, which is just exposing the SP in the portal.
-
What it is: A special kind of Service Principal managed entirely by Azure.
-
Where it’s used: Azure resources (VMs, App Services, Functions, etc.) can get a system-assigned or user-assigned managed identity.
-
Why it’s useful:
- No need to manage client secrets or certificates.
- Tokens are issued automatically by Azure.
-
Analogy: A managed identity is like a pre-configured service principal where Azure takes care of all the credential management.
-
How permissions are granted:
- During App Registration, you configure what APIs your app can request.
- At the Service Principal/Enterprise Application level, tenant admins decide what permissions and roles are actually granted.
-
Example:
- App Registration says “this app may need Microsoft Graph Mail.Read.”
- Tenant admin must consent at the Service Principal level to actually grant it.
- App Registration: The blueprint (global definition of the app).
- Service Principal: The app’s identity in a specific tenant.
- Enterprise Application: The portal view/management surface for the Service Principal.
- Managed Identity: An Azure-managed Service Principal tied to a resource, with no credential management.
Together, these provide a flexible but sometimes confusing identity model in Azure AD.