2.4 Application Identities, OAuth Consent & Managed Identities
Key Takeaways
- App registrations define the application object (blueprint); enterprise applications are the service principal instances that exist in a tenant and receive permissions, users, and policies
- Delegated permissions act on behalf of a signed-in user; application permissions run as the app itself without a user and always require admin consent
- User consent settings and admin consent (including admin consent workflow) control how OAuth permission grants are approved and reduce consent phishing risk
- System-assigned managed identities share the lifecycle of one Azure resource; user-assigned managed identities are standalone and can be shared across multiple resources
- Prefer managed identities over embedded secrets; use workload identity federation when external or multi-cloud workloads need Entra tokens without storing client secrets
2.4 Application Identities, OAuth Consent & Managed Identities
Quick Answer: Register apps as app registrations (application object); runtime access in a tenant uses the enterprise application / service principal. Grant delegated permissions for user-on-behalf-of flows and application permissions for daemon/app-only flows (admin consent required). Prefer managed identities over client secrets; pick system-assigned for one resource lifecycle or user-assigned when sharing identity across resources.
Human MFA and Conditional Access are only half of Entra secure access. SC-500 also tests application identities, OAuth consent, and managed identities for Azure resources—because attackers love leaked app secrets and over-permissioned service principals.
App Registrations vs Enterprise Applications
| Object | Also called | What it is | Where you manage |
|---|---|---|---|
| Application object | App registration | The multi-tenant-capable blueprint: redirect URIs, branding, app ID, credentials, requested API permissions, exposed scopes | Entra admin center → App registrations |
| Service principal | Enterprise application | The instance of that app in a specific tenant: who can sign in, what was consented, token config, owners | Entra admin center → Enterprise applications |
When you register an app in your home tenant, Entra creates both an application object and a service principal there. When another tenant consents to a multitenant app, Entra creates a service principal in that tenant from the application blueprint. Permissions and Conditional Access for “this app in this tenant” attach to the enterprise application / service principal, not only the registration blade.
Exam trap: Configuring redirect URIs and client secrets is app registration work; assigning users, reviewing permissions grants, and applying CA to the app is enterprise application / service principal work.
OAuth Permission Types
| Permission type | Acts as | User signed in? | Who can consent | Typical workload |
|---|---|---|---|---|
| Delegated | The signed-in user (app + user) | Yes | User (if allowed) or admin | Interactive apps, OBO middle tiers |
| Application | The application itself | No | Admin only | Daemons, background jobs, APIs without user context |
Delegated permissions
- Scope examples:
User.Read,Mail.Read(on behalf of the user) - Effective access is the intersection of what the app was granted and what the user is allowed to do
- Good default for user-facing apps
Application permissions
- Role examples:
User.Read.All,Mail.Readas app-only (names vary by resource) - App can access data without a user present—high blast radius if secrets leak
- Always require admin consent
- Prefer least privilege; avoid “*.ReadWrite.All” style grants without justification
User Consent vs Admin Consent
User consent
A user signs in and is prompted to allow the app to access data as them (delegated permissions that do not require admin). Tenant user consent settings can:
- Allow users to consent to apps for low-risk permissions
- Allow users to consent only for apps from verified publishers / selected permissions (recommended hardening)
- Do not allow user consent — all consent becomes admin-driven
Disabling open user consent is a common defense against consent phishing (malicious apps tricking users into granting Graph access).
Admin consent
A privileged admin grants permissions for the organization (tenant-wide) or reviews requests:
- Required for application permissions
- Required for many high-privilege delegated permissions
- Admin consent workflow lets users request admin approval with justification instead of dead-ending on “Need admin approval”
Reviewing and remediating grants
Security engineers should periodically:
- Open Enterprise applications → permissions / consent blades
- Review admin consent and user consent grants
- Remove unused or overprivileged grants
- Rotate or eliminate client secrets; prefer certificates or federated credentials
- Require assignment for sensitive apps so only intended users can sign in
Credentials for Apps (and Why to Avoid Them)
App-only access historically used:
- Client secrets (passwords for apps) — easy to leak into source control
- Certificates — better than secrets, still operationally heavy
- Federated credentials / workload identity federation — trust an external issuer (GitHub Actions, other clouds, or a managed identity as FIC) so no long-lived secret is stored in the app
SC-500 alignment: eliminate secrets where Azure can host the workload, using managed identities; use federation when the compute is outside Azure or needs an app registration without a secret.
Managed Identities for Azure Resources
A managed identity is an Entra identity for an Azure resource that can obtain tokens without developers handling credentials. Azure manages the credential material.
System-assigned vs user-assigned
| Property | System-assigned | User-assigned |
|---|---|---|
| Creation | Enabled on one Azure resource | Created as its own Azure resource |
| Lifecycle | Deleted when the parent resource is deleted | Independent; must be deleted explicitly |
| Sharing | Only that one resource uses it | Assign to many resources |
| Name | Matches the resource (slots have a slot-specific name pattern) | Name you choose |
| Common use | Single VM/app with its own identity | Scale sets, multiple apps sharing one identity; pre-authorize identity before compute exists; stable identity when compute is recycled |
Microsoft often recommends user-assigned for services that need shared or pre-provisioned identities, while system-assigned remains excellent for simple one-resource workloads.
How authorization works
- Enable system-assigned or create and assign a user-assigned managed identity on the source resource (VM, App Service, Function, AKS workload identity patterns, etc.)
- Grant the identity Azure RBAC (or data-plane roles) on the target (Key Vault, Storage, SQL, etc.)
- Code uses Azure Identity / MSAL libraries to request a token for the target resource’s audience
- No connection string password is required when the target supports Entra authentication
When to choose which
| Situation | Prefer |
|---|---|
| One App Service talks to one Key Vault and identity should die with the app | System-assigned |
| Five Functions need identical access to one Storage account | User-assigned (shared) |
| Blue/green or frequently replaced VMs must keep the same role assignments | User-assigned |
| Identity must be authorized before the compute resource exists | User-assigned |
| Strict one-to-one blast radius per resource | System-assigned |
Workload Identity Federation (Mention for SC-500)
Workload identity federation lets an app registration trust tokens from an external identity provider (or use a managed identity as a federated identity credential). Patterns:
- GitHub Actions OIDC → Entra app → deploy to Azure without storing a client secret in GitHub
- Kubernetes / AKS workload identity patterns
- Managed identity as FIC on an Entra app when a workload must act as a full application identity without secrets
You do not need every federation detail for SC-500, but you should recognize federation as the secret-less alternative when a classic app registration would otherwise need a client secret.
End-to-End Scenario
Scenario: A web API on Azure App Service reads blobs and calls Microsoft Graph as itself to list users for a sync job.
Secure design:
- Enable a system-assigned managed identity on the App Service (or user-assigned if multiple apps share access)
- Grant the identity Storage Blob Data Reader on the storage account (RBAC data plane)
- For Graph app-only calls, either:
- Use an app registration with least-privilege application permissions + admin consent, authenticating via federated credential to the managed identity / certificate—not a client secret in config, or
- Prefer Graph scenarios that can use narrower patterns where available
- Review the enterprise application permission grants quarterly
- Apply Conditional Access for workload identities if the tenant uses that control for risky app sign-ins
- Never put storage keys or Graph client secrets in app settings if managed identity / federation can replace them
Common Exam Traps
- App registration ≠ enterprise app — blueprint vs tenant instance.
- Application permissions always need admin consent — users cannot consent app-only roles.
- Delegated access is limited by the user’s own permissions — the app cannot exceed the user.
- System-assigned dies with the resource — role assignments go away with it; plan for that.
- Managed identity still needs RBAC/data permissions — identity alone is not access.
- Open user consent is a consent-phishing risk; tighten settings and use admin consent workflow.
Chapter Synthesis
| Control | Secures |
|---|---|
| PIM | Standing human privilege (JIT elevation) |
| Conditional Access | Real-time sign-in decisions |
| MFA / passwordless / strengths | Authentication quality |
| App registrations, consent, managed identities | Application and workload access without (or with tightly governed) secrets |
Together these fulfill the SC-500 skill: Secure access to resources by using Microsoft Entra ID. Key Vault and governance controls build on this foundation in the next chapters.
What is the relationship between an app registration and an enterprise application in Microsoft Entra ID?
A daemon process must read Microsoft Graph data with no signed-in user. Which permission and consent combination is required?
You need one Entra identity that three Azure Functions will share to access the same Key Vault, and the identity must remain if a Function app is deleted and redeployed. Which option fits best?
Security wants to reduce consent phishing where users grant risky OAuth permissions to malicious apps. Which Entra configuration directly addresses that risk?