Published on

Azure identities explained — Service Principal vs Managed Identity vs App Registration

Authors
  • avatar
    Name
    Krzysztof Kozłowski
    Twitter

I've been working with Azure for years. And I still get confused every time I move between blades in the portal.

You create an App Registration. Then you open Enterprise Applications and the same app is there too — with different fields. A tutorial says "create a Service Principal" — but the portal has no menu with that name. Someone else says "use a Managed Identity instead" — and that is a completely different blade.

Four names. They look like four different things.

They are not.

There are really only two objects

In Entra ID, there are two real object types. Everything else is a special case or a different view of the same thing.

  • App Registration is the definition of an app. It cannot sign in. It cannot get a role.
  • Service Principal is the identity — what your app actually is at runtime.
  • Managed Identity is a Service Principal that Azure creates and manages for you.
  • Enterprise Application is not a separate object. It is a portal view that shows Service Principals.

That is the whole picture. The rest is just smaller details.

App Registration — the definition

An App Registration says: "there is an app called X. Here is its redirect URI. Here are the API permissions it wants. Here are its secrets and certificates."

It cannot sign in. It cannot get a role. It is just a description in your tenant.

You create one when you need:

  • a sign-in app (web app, SPA, mobile)
  • an API that other apps will call
  • a background service that runs as itself
az ad app create --display-name "my-api"

On its own, this does not do anything yet.

Why split them at all?

Fair question — if every app needs a Service Principal to do anything, why not just merge them into one object?

The reason is multi-tenant apps.

The App Registration is the template. The Service Principal is the instance. One template can produce many instances — one per tenant where the app is used.

  • Build an internal API used only inside your company → one App Registration, one Service Principal, both in your tenant. The split feels pointless.
  • Build a SaaS that other companies sign in to (think Slack, Notion, GitHub OAuth) → one App Registration in your tenant, plus one Service Principal in every customer's tenant where someone agreed to use the app. Each customer gets their own RBAC, audit log, conditional access — on the same app.

For single-tenant work you barely notice the split. The design is built around the multi-tenant case. Single-tenant just inherits the same shape.

Service Principal — the actual identity

A Service Principal is what you get when you use an App Registration in a tenant. It is the identity that signs in, gets roles, and shows up in your audit logs.

The "all in one" command that most tutorials show first hides three steps in one line. It creates an App Registration, creates a Service Principal, and gives the SP a role:

az ad sp create-for-rbac --name "my-deploy-sp" --role Contributor

Enterprise Application — the same SP, different blade

This is the one that confused me the longest.

Enterprise Application is not a separate object. It is a portal view. It shows you a list of all Service Principals in your tenant — your own ones, Microsoft's, Gallery apps (Slack, GitHub, Salesforce), and any multi-tenant app that someone agreed to use here.

  • The App Registrations blade only shows apps that you defined in your tenant.
  • The Enterprise Applications blade shows everything that has a Service Principal here — no matter where it came from.

This is why you sometimes see "two of the same app" in the portal. It is the same Service Principal, just shown in two different views with different fields:

  • App Registrations: "you own this — API permissions, secrets, redirect URIs."
  • Enterprise Applications: "this is a usable identity — assigned users, SSO config, conditional access."

If you delete the Service Principal from Enterprise Applications, the App Registration is still there. You can create a new SP from it later.

Managed Identity — Azure handles the credentials

A Managed Identity is a Service Principal. Same object underneath. The difference: Azure creates it, rotates the credentials, and cleans up automatically. You have nothing to store and nothing to rotate.

Two types:

  • System-assigned — connected to one Azure resource. When you delete the resource, the identity is deleted too.
  • User-assigned — an independent identity that you create on its own. You can attach it to many resources.
resource "azurerm_user_assigned_identity" "app" {
  name                = "id-app"
  resource_group_name = azurerm_resource_group.this.name
  location            = azurerm_resource_group.this.location
}

In your app code, you can use the identity with no secret in your configuration:

using Azure.Identity;
var credential = new DefaultAzureCredential();

If you read the passwordless connections post, this is the identity that was running underneath.

Which one when

  • Your app runs in Azure and talks to other Azure services → Managed Identity. Always, if you can.
  • Your app runs outside Azure (GitHub Actions, on-prem CI) and needs to deploy to Azure → App Registration + Service Principal. Use OIDC federation if you can, or a client secret if you cannot.
  • You are building a multi-tenant SaaS → App Registration in your tenant. Service Principals appear in each customer's tenant when someone agrees to use the app.
  • You need a third-party SaaS for Single Sign-On (SSO) → use the Enterprise Applications blade and install the app from the Gallery.

One trap worth knowing

The IDs in Azure are confusing. Everybody mixes them up at least once.

  • Application ID (also called Client ID) belongs to the App Registration. It is the same in every tenant where a multi-tenant app is used.
  • Object ID is different for every object. The App Registration has its own. Each Service Principal has its own.
  • When you give an identity access to a resource (RBAC), you use the Object ID of the Service Principal — not the Application ID of the App Registration.

I made this mistake the first time I tried to give a Managed Identity access to Key Vault in Terraform. I kept passing the wrong ID and kept getting "principal not found."

Key takeaways

  • Two real Entra ID objects: App Registration (definition) and Service Principal (identity instance).
  • Enterprise Application is a portal view, not a separate object.
  • Managed Identity is a Service Principal managed by Azure. Use it whenever your workload runs in Azure.
  • For RBAC, use the Object ID of the Service Principal — not the Application ID of the App Registration.

What's next

This post is the concept layer. The natural next step is how Azure Workload Identity actually works — the OIDC token flow that lets a pod in AKS become a Managed Identity. No shared credentials anywhere in the cluster. I will publish that next.

If a specific identity confusion has bitten you, ping me on LinkedIn.