Delegated requests blur the line between what the service can do and what the user should be able to do. If those contexts are not evaluated together, a valid workload can exceed the user’s scope, creating privilege expansion that looks legitimate to the application but violates governance intent.
What breaks when on-behalf-of requests are not authorised separately?
The main thing that breaks is the security boundary between delegated action and direct user action. An application may correctly know who initiated the request, but still fail to check what the caller is allowed to do in delegated context. That creates a gap where the service’s standing authority can be applied too broadly, even when the end user would not qualify on their own.
Why separate authorisation is required for delegated flows
On-behalf-of flows are not simple pass-throughs. They introduce a second decision point: the service must be trusted to act, and the delegated act must also be valid for the original user context. When those checks are collapsed into one, the application often treats a delegated token as if it were equivalent to a fully authorised user session. That is where scope inflation starts.
A separate decision prevents a workload from becoming a shortcut around normal access rules. It forces the system to evaluate whether the action is permitted for the user, for the service, and for the combined delegated context. That matters most when the downstream operation is high impact, such as data retrieval, privilege-bearing updates, or cross-tenant access.
In practical terms, the failure is not just “bad authentication”. It is an authorisation design flaw. If the service can exchange identity context but no policy checks are applied to the resulting on-behalf-of request, the service may act as an overbroad proxy. That is why delegation needs explicit policy, not just token handling.
What privilege expansion looks like in real systems
The most common symptom is that a request appears legitimate because it arrived through a trusted workload, yet it exceeds the original user’s rights. That can happen when the service’s baseline permissions are used as the effective permission set, rather than intersecting them with the user’s actual scope. The result is privilege expansion that is invisible to the application unless the delegated context is checked separately.
This also creates governance drift. Audit logs may show a valid authenticated service and a valid end user, but not the fact that the delegated operation crossed a policy boundary. Without separate authorisation, reviews can miss that the workload is effectively amplifying user intent beyond what the user should control. For delegation patterns, that is exactly the class of issue covered by RFC 8693: OAuth 2.0 Token Exchange, because token exchange is only safe when the resulting token is constrained to the intended delegated use.
The same pattern appears in agentic and service-to-service environments when a system assumes “trusted caller” means “trusted action”. That assumption is too coarse. The caller may be trustworthy as a workload and still be outside scope for a specific user-bound action. Separate authorisation is what keeps delegation from turning into implicit full impersonation.
Where delegation control fails most often
Breakdowns usually occur at the policy boundary, not the transport layer. Teams often validate the initial login or token issuance correctly, but then skip a second policy evaluation when the service acts on the user’s behalf. The application may therefore honour the delegated token without checking whether the action is consistent with the user’s entitlements, the service’s delegated rights, and any resource-level restrictions.
That risk is amplified when authorisation is embedded in application code instead of being externalised and consistently enforced. A strong delegated model depends on the same basic principle as fine-grained access control: the decision must be explicit, contextual, and testable. Authorisation Models Guide is useful here because it frames RBAC, ABAC, ReBAC and policy-based access as distinct ways to evaluate whether a delegated action should proceed.
When organisations do this well, they do not rely on the existence of a valid token as proof that the operation is allowed. They require a policy outcome for the delegated request itself. That is the difference between “the service may call” and “this service may call this resource for this user right now.”
Risk and Threat Considerations
Delegated flows are attractive to attackers and also fragile under misconfiguration because they combine two trust decisions in one path. If the service’s standing authority is broader than the user’s intent, an attacker who obtains or abuses the delegated path can reach data or functions that should have remained out of scope.
Failure mechanism: The system treats a delegated request as authorized once the service is trusted, but it never rechecks whether the specific user-context action is permitted, so the service becomes an unintended privilege amplifier.
Impact: Attackers or overprivileged workflows can perform legitimate-looking actions beyond the user’s entitlement, leading to unauthorised data access, privilege escalation, and governance failures that are hard to spot in logs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Delegated requests need function-level checks on the effective action. |
| Recommendation — Enforce separate authorization for each delegated function before executing it. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Separate policy enforcement is required for the delegated request, not just the caller. |
| IA-2 — Identification and Authentication (Organizational Users) | The delegated flow still depends on reliable user identity at the access decision point. | |
| IA-9 — Identification and Authentication (Service and Network Access Devices) | On-behalf-of flows rely on service-to-service authentication and trust. | |
| Recommendation — Apply AC-3 to enforce authorization on the effective delegated action. Require strong authentication before evaluating delegated access. Use IA-9 to authenticate the calling service before token exchange. | ||
| NIST Zero Trust (SP 800-207) | PA-1 — Policy Decision and Enforcement | Zero trust requires explicit policy decisions for each delegated request. |
| Recommendation — Evaluate each on-behalf-of request with a separate policy decision. | ||
Practitioner Guidance
What to verify: Confirm that the delegated token or request is evaluated against a separate policy decision for the user context, not only against the service’s own credentials or baseline permissions. If the only check is “was the caller authenticated?”, the design is incomplete.
Decision rule: If the action can change data, reveal sensitive records, or cross an administrative boundary, require explicit delegated authorisation and scope intersection. If the service is merely relaying input without exercising authority, keep the policy lighter but still auditable.
Practitioner takeaway: On-behalf-of is safe only when delegation is constrained as tightly as direct access, because the moment the service’s authority substitutes for the user’s scope, the application has created a legitimate-looking privilege escalation path.
Related resources from NHI Mgmt Group
- What breaks when workbook features can silently make network requests on a user’s behalf?
- What breaks when a web application lets attackers trigger server-side requests on their behalf?
- How should security teams authorize API requests made by applications on behalf of users?
- What breaks when identity recovery is treated separately from identity defence?