Overview
Entra ID (formerly Azure Active Directory) is Azure's identity provider for both human sign-in and workload-to-workload authentication, every user, and every application that needs to authenticate, has an identity that traces back to it. Two separate role systems then govern what an authenticated identity can actually do: Entra ID roles for managing identity and directory settings themselves, and Azure RBAC for managing Azure resources. For workloads specifically, managed identities remove the most common source of credential-handling risk, client secrets that need to be stored and rotated, by letting Azure manage the credential entirely.
Quick Reference
| Concept | Governs | Example |
|---|---|---|
| Entra ID roles | Identity/directory management | Global Administrator, User Administrator |
| Azure RBAC | Access to Azure resources | Contributor, Reader, custom roles |
| App registration | An application's identity | Client ID, authentication configuration |
| Managed identity | Credential-free workload authentication | A VM or App Service authenticating to Key Vault |
Syntax
# Enable a system-assigned managed identity on an App Service -
# no client secret to store or rotate.
az webapp identity assign --name my-api --resource-group rg-appExamples
# Grant that managed identity access to a Key Vault secret via
# Azure RBAC, scoped to just that resource.
az role assignment create \
--assignee <managed-identity-object-id> \
--role "Key Vault Secrets User" \
--scope /subscriptions/.../resourceGroups/rg-app/providers/Microsoft.KeyVault/vaults/kv-appPrefer managed identities over client secrets
Whenever a workload runs on Azure compute, a managed identity removes the entire credential-storage and rotation burden. Reach for a service principal with a client secret only when the workload runs outside Azure and has no other option.
Visual Diagram
Common Mistakes
- Storing a service principal's client secret in application config or source control instead of using a managed identity where the workload runs on Azure compute.
- Confusing Entra ID roles with Azure RBAC roles, granting someone Global Administrator when they only needed Contributor access to a specific resource group, or vice versa.
- Granting broad RBAC scope (subscription-level Contributor) for a task that only needed access to one resource group or resource.
- Forgetting that app registrations and their credentials need their own lifecycle management, expired client secrets on a forgotten app registration are a common source of unexpected outages.
Performance
- Managed identity token acquisition is handled transparently by the Azure SDKs and cached automatically, adding negligible overhead compared to manually managing and refreshing a client secret.
- Entra ID authentication and RBAC evaluation happen on the request path for resource access but are designed for low latency; the practical concern is correctness of role scope, not runtime cost.
Best Practices
- Use managed identities by default for any workload running on Azure compute that needs to authenticate to another Azure service.
- Scope Azure RBAC role assignments as narrowly as possible, a specific resource or resource group rather than a subscription, unless the access genuinely needs to be that broad.
- Separate Entra ID directory administration roles from Azure resource RBAC roles when assigning access; they answer different questions and shouldn't default to the same broad grant.
- Treat any remaining client secrets (for workloads that can't use managed identities) as sensitive, rotate them on a schedule, and store them in Key Vault rather than application config.