Application and Workload Identities in Microsoft Entra ID
Ninth in this series on Microsoft Entra ID, covering how applications and automated workloads — as opposed to human users — get represented and secured: application objects, service principals, app roles, managed identities, and delegated permissions.
Application objects and service principals
When a user or an application requests access to a resource, it does so through a security principal, which defines the access policy and permissions that principal holds in the tenant — supporting both authentication at sign-in and authorisation at resource access. An app can be represented in Microsoft Entra ID in two related ways: as an application object, and via a service principal.
The application object is, with some exceptions, the definition of the app — it's what tells the service how to issue tokens based on the object's configured settings, and it exists only in its home directory, even for a multi-tenant app used via service principals in other tenants. The service principal is the instance of that app — it generally references the application object, and multiple service principals can reference the same one. Service principals are what actually govern the app's connection to Microsoft Entra ID in a given directory; they're the local instance, where the application object is the global template. Practically, the service principal is what matters for access control day to day: it's the local identity and security context the application operates under in a given tenant, tracking which users or groups are assigned to use the app, what permissions the tenant admin has granted, and which secrets or certificates it authenticates with.
App roles
App roles are how you layer role-based access control on top of an application. You define app roles on the application registration itself — during app registration, in the Microsoft Entra admin centre — and each role maps to a set of permissions you decide on. App roles can be assigned to users, to groups, or to the service principal of another application or a managed identity, so the same mechanism covers both human and workload access. When a user or service principal signs in, Microsoft Entra ID emits a roles claim in the token for each role it holds, which the application then reads to make its own authorization decisions.
Types of service principals
There are three types of service principal.
An application service principal is the local, per-tenant instance of a global app object — created in each tenant where the app is used, referencing the one globally unique object, and inheriting certain properties from it. This is the object that actually defines what the app can do in that specific tenant: who can access it, and what resources it can reach. If the application object is the global template, the application service principal is the local representation created from it for a given tenant.
A managed identity service principal represents a managed identity — eliminating the need to manage credentials at all. When you enable a managed identity, Entra ID creates the corresponding service principal in your tenant automatically. A few terms that come with this: the Client ID is the unique ID tied to the app and service principal when the identity is provisioned; the Object ID is the service principal object representing the managed identity; and the Azure Instance Metadata Service is a REST endpoint Azure Resource Manager enables when it creates a VM, accessible only from inside that VM.
A legacy service principal represents an app created before app registrations existed, or created through an older configuration path. It can carry credentials, service principal names, reply URLs, and other editable properties, but critically it has no associated app registration — a distinguishing feature versus the other two types.
Managed identities
Azure managed identity is a Microsoft Entra ID feature you can use at no charge — it's available in every edition, including Free. It automatically creates identities that let apps authenticate to Azure resources without you managing any credentials directly; in App Service, for instance, it works with no extra cost and no required configuration.
Functionally, a managed identity combines Microsoft Entra authentication with Azure RBAC. Because Azure handles credential rotation and expiry in the background, you never need to rotate secrets or worry about expiring certificates — you just use the token the platform provides to call the target service. For resources that support system-assigned identities, you can enable or disable the identity at the resource level, grant permissions through RBAC roles, and review activity through both Azure Activity logs (for CRUD operations) and Microsoft Entra sign-in logs.
| System-assigned | User-assigned | |
|---|---|---|
| Lifecycle | Tied to the resource instance — deleting the resource deletes the identity automatically | Independent — created and managed as its own Azure resource |
| Scope | One identity per resource; only that resource can use it to request tokens | Can be assigned to multiple resource instances at once |
| Typical fit | A single resource, e.g. one VM | Shared across resources that need the same identity — e.g. a fleet of web servers, where a system-assigned identity per VM would mean managing permissions separately for each one |
Service principal vs. managed identity
Framed as manual versus automated identity: a service principal is the local representation of an app registration in a specific tenant, used by applications, hosted services, and automation tools to access Azure resources. You manage its credentials yourself — a client secret or a certificate — and you're responsible for keeping that secret safe (typically in Azure Key Vault) and rotating it before expiry. In exchange, it's usable anywhere: on-premises, in another cloud, on a local dev machine, or in Azure.
A managed identity is a service principal Azure manages automatically, removing credential management entirely — there's nothing for you to see, store, or rotate; Azure handles the handshake behind the scenes, and your only responsibility is turning it on. The trade-off is scope: it only works for resources actually running inside Azure (VMs, App Service, Functions, and so on) — it has no equivalent portability to on-premises or other clouds.
Delegated permissions
A delegated permission applies when an app acts on behalf of a signed-in user — reading their calendar, for example — rather than acting with its own standalone identity. In this model, the app receives an access token representing both the app and the user together, and the permissions granted are scoped accordingly, for example Calendars.Read or Calendars.ReadWrite in Microsoft Graph.