Identity Identity operations premium

Delegated permission

Delegated permission is an application permission model where the app acts on behalf of a signed-in user instead of acting as itself. In Azure, it helps teams allow user-facing apps to call APIs with user context while respecting consent, tenant policy, and the user’s effective access. Plainly, it is a named operating concept that connects design intent with live configuration, evidence, ownership, and production impact. A useful glossary entry should show where it lives, who controls it, what depends on it, and what signal proves it is working.

Back to glossary browser Open Microsoft Learn source
Aliases
OAuth delegated permission, Microsoft Graph delegated permission, user delegated permission
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-13

Microsoft Learn

A delegated permission is a Microsoft identity platform permission that lets an application act on behalf of a signed-in user, limited by both the granted permission and the user’s own access.

Microsoft Learn: Permissions and consent in the Microsoft identity platform2026-05-13

Technical context

Technically, Delegated permission appears in Microsoft Entra app registrations, API permissions, consent records, access tokens, scopes, enterprise applications, and Microsoft Graph calls and interacts with Microsoft Entra ID, Microsoft identity platform, Microsoft Graph, and App registration. Configuration is reviewed through OAuth scopes, admin consent, user consent policy, and token claims, while operators validate live state through granted scopes, consent status, access token scp claim, and service principal permissions. Scope matters because the same word can refer to a portal setting, API property, runtime behavior, or governance control.

Why it matters

Delegated permission matters because it turns architecture language into something teams can secure, monitor, troubleshoot, and explain under pressure. When it is documented shallowly, engineers may change the wrong resource, policy, identity, database, queue, workspace, or path while the real dependency remains untouched. In enterprise Azure projects, the value is shared language: platform, security, data, finance, and operations teams can discuss the same object without guessing. That reduces incident time, improves audit evidence, prevents avoidable rework, and makes migrations safer because downstream consumers and failure modes are visible before release. Treat Delegated permission as production owned when scheduled jobs, regulated data, customer traffic, or security monitoring depends on it.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

In app registrations, delegated permissions appear under API permissions as scopes that require user or administrator consent during production review before an approved change when operators collect evidence.

Signal 02

In access tokens, delegated permissions appear in the scp claim and reflect what the app can do for the signed-in user during production review before an approved change.

Signal 03

In consent reviews, delegated permissions appear when administrators decide whether an app should act on users’ behalf for specific APIs during production review before an approved change.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Let a web or desktop app call Microsoft Graph using the signed-in user’s context.
  • Review consented scopes before approving an enterprise application.
  • Troubleshoot why an app can access only resources the current user can access.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

Delegated permission in action for professional services

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Summit Legal Group, a professional services organization, needed to address a client portal needed to read each user’s calendar without granting app-wide mailbox access. The architecture team used Delegated permission as the control point for a measurable production improvement.

Business/Technical Objectives
  • Use least-privilege Microsoft Graph scopes
  • Require administrator consent for sensitive access
  • Prove access was user-context limited
Solution Using Delegated permission

The identity team configured Delegated permission on the app registration for the required Microsoft Graph scopes. Admin consent was approved through a ticketed process, Conditional Access governed sign-ins, and token claims were reviewed to confirm the scp value. The app could read only what the signed-in user could already access. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps. The design was tested in a lower environment so security, operations, and finance teams could review the impact before production rollout. Support staff received clear checks for resource state, identity, cost, telemetry, and downstream dependency health. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps.

Results & Business Impact
  • Application permissions were avoided entirely
  • Consent review time dropped from five days to two
  • No user could access another user’s calendar through the portal
Key Takeaway for Glossary Readers

Delegated permission is the right fit when an application should act with signed-in user context.

Case study 02

Delegated permission in action for business intelligence consulting

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Northwind Analytics, a business intelligence consulting organization, needed to address an internal reporting add-in requested broad permissions that triggered tenant security review. The architecture team used Delegated permission as the control point for a measurable production improvement.

Business/Technical Objectives
  • Reduce requested scopes
  • Separate user delegated access from daemon jobs
  • Document consent decisions clearly
Solution Using Delegated permission

Architects reviewed the app registration and replaced unnecessary permissions with targeted Delegated permission scopes. Background refreshes moved to a separate managed identity pattern, while the user add-in retained delegated Microsoft Graph access. Enterprise application records and sign-in logs were added to the runbook for future reviews. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps. The design was tested in a lower environment so security, operations, and finance teams could review the impact before production rollout. Support staff received clear checks for resource state, identity, cost, telemetry, and downstream dependency health. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps.

Results & Business Impact
  • Requested scopes dropped from nine to three
  • Security approval cycle improved by 60 percent
  • Failed user-consent tickets decreased across the pilot group
Key Takeaway for Glossary Readers

Delegated permission helps teams avoid overprivileged apps when user context is sufficient.

Case study 03

Delegated permission in action for public sector citizen services

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

CivicPortal Services, a public sector citizen services organization, needed to address a case-management app needed citizen-service workers to update records through Graph-connected APIs. The architecture team used Delegated permission as the control point for a measurable production improvement.

Business/Technical Objectives
  • Respect worker-specific authorization
  • Enable audited admin consent
  • Troubleshoot token scope issues faster
Solution Using Delegated permission

The application team used Delegated permission so API calls executed on behalf of the signed-in worker. Admin consent was limited to required scopes, and support engineers learned to inspect the scp claim, enterprise application grant, and user group membership. Conditional Access protected high-risk sign-ins. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps. The design was tested in a lower environment so security, operations, and finance teams could review the impact before production rollout. Support staff received clear checks for resource state, identity, cost, telemetry, and downstream dependency health. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps. The design was tested in a lower environment so security, operations, and finance teams could review the impact before production rollout.

Results & Business Impact
  • Token-scope troubleshooting time fell 55 percent
  • Unauthorized record updates were blocked by user access limits
  • Consent evidence was available for quarterly review
Key Takeaway for Glossary Readers

Delegated permission combines application integration with the guardrails of user identity.

Why use Azure CLI for this?

CLI checks for Delegated permission are useful because they turn portal assumptions into repeatable evidence. Start with read-only commands that show the resource, definition, permissions, metrics, or runtime state, then compare the output with the intended design. Use mutating commands only through an approved change process with owner, rollback, and impact notes. For Delegated permission, evidence should be captured before and after production changes.

CLI use cases

  • Let a web or desktop app call Microsoft Graph using the signed-in user’s context.
  • Review consented scopes before approving an enterprise application.
  • Troubleshoot why an app can access only resources the current user can access.

Before you run CLI

  • Run az account show, confirm tenant and subscription, and verify the operator identity has approved read access for the exact scope.
  • Confirm the resource group, workspace, account, queue, container, file system, app registration, or security plan name before collecting evidence.
  • Prefer read-only commands first; review any command that changes access, cost, compute state, network exposure, message settlement, or production data.

What output tells you

  • Whether the object exists in the expected Azure resource, tenant, workspace, account, namespace, or governance boundary.
  • Which owner, identity, permission, status, metric, endpoint, throughput setting, ACL, security plan, or runtime value is visible to the current operator.
  • Whether the issue is missing scope, permission drift, wrong environment, network misconfiguration, stale deployment, service health, or resource state.

Mapped Azure CLI commands

Delegated permission operational checks

direct
az ad app show --id <application-id>
az ad appdiscoverIdentity
read-only Microsoft docs
az ad sp show --id <application-id>
az ad spdiscoverIdentity
read-only Microsoft docs
az ad app permission list --id <application-id>
az ad app permissiondiscoverIdentity
read-only Microsoft docs
az ad app permission admin-consent --id <application-id>
az ad app permissionsecureIdentity
mutating Microsoft docs

Architecture context

Delegated permission belongs to Identity architecture decisions where identity, networking, monitoring, cost ownership, and production support need shared evidence.

Security

Security for Delegated permission starts with least privilege, identity clarity, and evidence that access matches the workload classification. Review least-privilege scopes, admin consent workflow, conditional access, token audience, and sensitive Graph permissions before approving production use. A common failure is assuming that a successful portal action, query, message receive, or scan result proves the design is secure. Use Microsoft Entra groups, managed identities, role assignments, private connectivity, audit logs, and service-specific privileges where applicable. Keep exceptions ticketed, time-bounded, and tied to a named owner. For regulated workloads, align the configuration with classification, retention, break-glass, and incident-response procedures. Remove broad access, stale secrets, unreviewed public paths, and undocumented administrator permissions before Delegated permission becomes an incident path.

Cost

Cost for Delegated permission appears through compute duration, request units, protected endpoints, storage growth, diagnostic retention, operational toil, and the downstream work triggered by bad configuration. Review manual consent reviews, support tickets, overprivileged app remediation, failed integrations, and audit evidence effort before expanding production use. Some costs are direct, such as DWU compute, container app profile instances, Cosmos DB throughput, security plan coverage, or storage; others are indirect, such as retries, manual evidence collection, delayed restores, and failed jobs. Tag related Azure resources, monitor usage, and separate exploratory work from production workloads. A cost review should connect spend to a real owner and measurable value.

Reliability

Reliability for Delegated permission depends on repeatable configuration, tested dependencies, and clear failure signals. Watch missing consent, wrong tenant, expired tokens, user access changes, and scope mismatch because drift often appears later as missed schedules, failed restores, broken private connectivity, stuck messages, slow queries, or incomplete security coverage. Use lower environments, source-controlled definitions where possible, deployment checks, monitoring, and rollback notes before changing production. Operators should know which resource, endpoint, identity, data path, queue, database, or downstream system fails first and which log or metric proves the failure. The goal is predictable recovery: detect Delegated permission drift, protect data, restore service, and explain the incident without guessing.

Performance

Performance for Delegated permission depends on workload shape, data layout, network path, scale limits, governance choices, and the compute or broker path used to access it. Review token acquisition latency, Graph throttling, incremental consent flow, cache behavior, and API retry pattern before increasing capacity. The better fix might be scheduling, query tuning, partition design, throughput allocation, lock handling, file compaction, path validation, or clearer orchestration. Measure with representative traffic and data, not a tiny sample that hides production behavior. Operators should connect symptoms to evidence: latency, queue depth, RU consumption, CPU, scan volume, failed stages, status changes, or run duration.

Operations

Operations for Delegated permission should focus on ownership, observability, and safe repeatability. Standardize naming, tags, owner groups, environment labels, diagnostic destinations, runbook links, and change approvals so support teams do not reverse-engineer the design during an incident. Use read-only CLI, API, SQL, or portal checks first, then compare live state with the intended configuration. For production, connect alerts, audit events, cost records, access reviews, and release notes to the same term. The support question should be simple: who owns it, what changed, and what proves the current state?. Capture owner, scope, evidence, and rollback before changing Delegated permission in a production environment.

Common mistakes

  • Changing production before checking the exact owner, scope, downstream dependency, monitoring evidence, and rollback impact.
  • Using a portal screenshot as the only record when CLI, API, audit logs, SQL, or source-controlled configuration can provide repeatable evidence.
  • Assuming management-plane permissions, data-plane permissions, and service-specific privileges are granted and reviewed by the same team.