Plan and implement workload identities
Two sides of an application
Registering an app creates an app registration - the definition: redirect URIs, secrets or certificates, API permissions, exposed scopes, and app roles. Consenting to that app creates a service principal in your tenant, the local identity that actually holds role assignments and access. A multi-tenant app has one registration but a service principal in every tenant that consents. Application permissions are app-only and always require admin consent; delegated permissions act as the signed-in user.
Managed identities
A system-assigned managed identity is created with an Azure resource and is deleted with it. A user-assigned identity is standalone and can be attached to many resources. Neither can cross tenant boundaries or be assigned directory roles directly, but both can receive Azure RBAC roles and Graph app roles.
Workload identity federation
Instead of a client secret, configure a federated credential that trusts tokens from an external issuer such as GitHub Actions, Azure DevOps, or a Kubernetes cluster. There is no secret to rotate, which makes it the preferred pattern for pipelines.
Traps
- Deleting the app registration leaves an orphaned service principal; remove the enterprise app to actually revoke access.
- Client secrets expire silently - certificates and federation avoid outages.
- Conditional Access for workload identities requires Workload Identities Premium and targets service principals, not users.
- Users who cannot grant consent use the admin consent workflow to submit a request for approval.
Rule of thumb
Inside Azure, use a managed identity. Outside Azure, use workload identity federation. Fall back to a client secret only when neither fits.