OAuth Delegation

How OAuth Delegation Works

OAuth delegation is fundamentally about consented, limited access: a user or organisation grants an application an access path, and the application then acts within the scopes and constraints that were approved. That makes the model useful for integrations, but also means the trust decision is concentrated in the authorisation boundary rather than in the app itself.

At a protocol level, delegation is not the same as sharing a password. The application receives tokens or comparable authorisation artifacts that let it call protected resources on the user’s or organisation’s behalf. The security value comes from scoping, audience restriction, expiration and the ability to revoke or narrow access without exposing primary credentials.

Because this term sits inside the OAuth family, readers often benefit from the underlying standard itself: RFC 6749: The OAuth 2.0 Authorization Framework defines the roles and grants that make delegated access possible.

Why Delegation Becomes Risky

The central danger is not delegation itself, but overbroad or weakly governed delegation. If scopes are too wide, a single connected app can gain more data or capability than the business actually intended. If the app is later compromised, the attacker inherits whatever authority the app was allowed to exercise.

This is why OAuth delegation can become a high-value persistence and exfiltration path. A malicious or compromised app does not need a user’s password to do damage; it only needs the delegated trust relationship to remain valid long enough to use the granted access.

That is also why modern OAuth guidance stresses sender-constrained tokens, audience restriction and tighter consent handling. Those controls reduce the chance that a stolen token or misdirected grant turns into broad downstream access.

Common Delegation Patterns and Security Boundaries

OAuth delegation appears in several common patterns: user-consented third-party apps, service-to-service access, on-behalf-of flows and token exchange. The key security question in each case is the same, who is allowed to act, for which resource, and under what conditions.

Where applications call APIs on behalf of users, the token often represents a delegated authority chain rather than a direct login session. That chain can be safe when the resource boundaries are narrow, but it becomes fragile when applications reuse tokens across services or when consent is treated as a one-time event instead of an ongoing governance decision.

For that reason, delegated access should be understood alongside the resource server and token model, not just the client app. RFC 8693: OAuth 2.0 Token Exchange is especially relevant where one token is transformed into another for on-behalf-of or intermediary access, and RFC 8707: Resource Indicators for OAuth 2.0 helps narrow the blast radius by binding tokens to a specific resource audience.

How to Assess and Govern Delegated Access

Organisations should treat delegation as an inventory and review problem, not only an application feature. The practical questions are which apps have consent, which scopes they hold, which resources they can reach and whether those grants still match business need.

That review becomes more important when delegation involves external apps, sensitive data or long-lived grants. If an app is no longer needed, if its scope is broader than expected, or if its vendor posture changes, the delegated relationship should be reconsidered rather than assumed safe by default.

Good governance also depends on clear protocol choices and current security practice. RFC 9700: Best Current Practice for OAuth 2.0 Security is the strongest general reference for reducing common OAuth weaknesses, while the OAuth 2.0 and OpenID Connect Guide for Identity Teams is a useful internal guide for understanding scopes, grant types and the mistakes that most often weaken delegated access.

Compromise, Detection and Recovery Considerations

Once delegation is abused, the compromise often looks like legitimate API activity, which makes detection harder than with a password theft event. Unusual consent grants, unexpected token use, access from unfamiliar applications or data access patterns that exceed the app’s normal function are all warning signs.

Recovery is not just about disabling the app. Teams may need to revoke grants, rotate related secrets where relevant, invalidate active tokens, review any downstream data access and check whether the app used delegated rights to create new trust links. A post-incident review should ask whether the original consent model was too permissive, whether token protections were strong enough and whether the connected app should have been trusted at all.

Real-world abuse of delegated OAuth trust is well documented, including consent-phishing and malicious app patterns such as Microsoft verified publisher OAuth phishing 2022 and CoPhish OAuth phishing via Copilot Studio, both of which show how delegated access can be turned into token theft and persistent access.

Risk and Threat Considerations

OAuth delegation creates a trust bridge, so the main risk is that the bridge can be wider, longer-lived or more reusable than the business expects. If the connected application is compromised, the attacker can act with the app’s delegated authority and may avoid the friction of password resets or interactive MFA prompts.

Failure mechanism: Overbroad scopes, weak consent governance, token theft, or a compromised connected application can turn a legitimate delegation into unauthorized access, data exfiltration, or persistence.

Impact: The resulting exposure can include mailbox access, API misuse, sensitive data retrieval, and difficult-to-detect abuse of a trusted integration until grants are revoked and related tokens are invalidated.

Practitioner Guidance

Governance implication: Treat delegated access as an owned trust relationship, not a one-time setup task. Review which apps are authorised, what scopes they hold, and whether each grant still reflects business need, vendor trust and data sensitivity.

What to watch for: Pay special attention to high-impact scopes, long-lived consent, unusual third-party apps, and any integration that can access more resources than its stated function requires. Where possible, prefer narrow audiences, short-lived tokens and stronger token-binding controls.

Practitioner takeaway: The safest OAuth delegation is the one that is narrow, observable and easy to revoke when the trust relationship no longer deserves to exist.

Related resources from NHI Mgmt Group

• What breaks when OAuth is used as the only control for agent-to-agent delegation?
• What is the difference between delegation and impersonation in OAuth-based agent workflows?
• What is the difference between domain-wide delegation and per-user OAuth access in an enterprise knowledge retrieval setup?
• What is the difference between OAuth-based authorization and capability delegation for agentic AI?