Workload identity types: app object vs service principal vs managed identity
Verdict: A user-assigned identity survives recycled compute and attaches to many resources; a system-assigned one dies with its resource. A federated credential removes stored secrets entirely. Permissions are granted to the service principal.
| Criterion | App registration | Service principal | System-assigned identity | User-assigned identity | Federated credential |
|---|---|---|---|---|---|
| What it is | Application object in the home tenant | Local tenant representation that holds permissions | Managed identity tied to one resource | Standalone managed identity | Trust that swaps a token for an app token |
| Lifecycle | Lives in the home tenant only | Created per tenant on consent | Deleted with its resource | Independent; deleted explicitly | Attached to an Entra app |
| Choose when | Define a multi-tenant app once | Grant roles or API permissions | One resource, no shared identity needed | Recycled scale-set instances need one stable identity | A workload must act as an app with no stored secret |
Rules
- When a tenant consents to a multi-tenant app, a service principal (an enterprise application) is created in that tenant; the app registration stays home.
- Choose a user-assigned managed identity for recycled scale-set instances so they keep authenticating as one consistent identity.
- Configure a VM managed identity as a federated credential on an Entra app so the workload acts as that app with no stored secret.
- The workload identity object types in Entra ID are the application object, the service principal, and the managed identity.
Traps
- A system-assigned identity is unique per resource and deleted with it, so recycled instances would not share an identity.
- Storing a client secret in Key Vault only relocates the credential; a federated credential removes it entirely.
- Roles and API permissions attach to the service principal, not directly to the application object.