Impersonation makes the downstream resource see the actor as the user, so the intermediary is effectively hidden from the receiving service. Delegation keeps the actor visible and adds evidence that the request is being made on behalf of the user. In practice, impersonation is simpler, while delegation provides stronger transparency and audit value.
Why OAuth token exchange treats impersonation and delegation differently
OAuth token exchange separates who the resource server should see from who initiated the request. Impersonation makes the downstream service treat the call as if it came from the user, while delegation preserves the acting party and carries proof that the request is on behalf of that user. The difference matters because it changes auditability, authorization decisions, and trust boundaries.
That distinction is why token exchange is not just another way to mint an access token. In delegated flows, the exchanged token usually needs to preserve actor context, subject context, or both, so the receiving service can evaluate the request as an on-behalf-of action rather than a direct user action.
What impersonation changes in the trust model
Impersonation hides the intermediary from the resource server. The receiving service sees the user identity and does not get a clear signal that another system, service, or agent is operating in the middle. That can simplify integration when a backend must complete work exactly as the user would, but it also reduces transparency and makes attribution harder.
In practice, impersonation is strongest when the downstream system only needs a single effective subject identity and the intermediary is not supposed to be part of the authorization story. It is weaker when investigators, auditors, or policy engines need to distinguish direct user action from mediated action, because the hidden actor is no longer obvious from the token alone.
What delegation preserves that impersonation does not
Delegation keeps the acting component visible and adds evidence that the request is being made on behalf of the user. That usually means the token or its claims can express an actor, an original subject, or an equivalent on-behalf-of relationship so the resource server can make more nuanced decisions and retain better logs.
This is the better fit when the intermediary has its own responsibilities, such as a workflow engine, broker, API gateway, or agent that must remain accountable for its actions. It gives defenders a cleaner path to separation of duties, because the downstream service can tell the difference between the principal whose rights are being used and the component that is exercising them.
How to choose the right model for a token exchange design
Use impersonation when the business or technical requirement is “act exactly as the user” and there is no strong need to preserve the intermediary’s identity in the receiving system. Use delegation when the intermediary’s role must remain visible, when approval chains matter, or when you need stronger traceability across service hops.
The design question is not only whether access succeeds, but what evidence the downstream system will retain after the call completes. For an on-behalf-of flow, the most useful test is whether a reviewer can reconstruct both the effective subject and the acting component without having to infer them from logs alone.
For a broader overview of how these choices fit into OAuth 2.0 and token exchange patterns, see OAuth Token Exchange and Delegation Guide. For the underlying protocol mechanics, RFC 8693: OAuth 2.0 Token Exchange is the key reference.
Risk and Threat Considerations
Impersonation increases the chance of over-trust because the downstream service cannot easily see that a broker or automation layer was involved. Delegation reduces that blind spot, which improves auditability and makes it harder for a compromised intermediary to blend in as the end user. The security question is often not whether the call is valid, but whether the visible identity chain is sufficient to detect abuse.
Failure mechanism: When actor context is stripped or poorly represented, an intermediary can gain effective user-level reach without leaving a reliable trace of its own participation. That can weaken fraud detection, incident reconstruction, and policy enforcement across chained services.
Impact: Teams may approve a design that works functionally but leaves too little evidence to distinguish legitimate on-behalf-of access from unauthorized impersonation, making misuse harder to spot and harder to prove after the fact.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | OAuth token exchange preserves who is authenticated in user-facing flows. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Delegated token exchange often spans external apps or services acting for a user. | |
| AU-3 — Content of Audit Records | Delegation needs actor context in logs so on-behalf-of actions remain attributable. | |
| Recommendation — Use IA-2 to verify user identity before issuing tokens on their behalf. Use IA-9 to authenticate external actors and preserve accountable access chains. Record actor, subject, and token-exchange context in audit events. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Token-exchange choices affect whether intermediaries can invoke privileged functions transparently. |
| Recommendation — Enforce function-level authorization on the effective subject and the acting component. | ||
Practitioner Guidance
What to verify: Confirm whether the resource server needs only the user as the effective subject, or whether it must also know the acting component. If the answer affects audit, approval, or escalation logic, delegation is usually the safer design choice.
Decision rule: If the intermediary can change business state, reach sensitive data, or trigger downstream actions, require an explicit actor relationship in the exchanged token rather than relying on hidden passthrough. If the intermediary is purely mechanical and should not be distinguishable, impersonation may be acceptable but should be tightly bounded.
Practitioner takeaway: The real trade-off is not convenience versus complexity, but opacity versus accountability, impersonation optimizes for simplicity, while delegation optimizes for traceability and safer operational control.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org