What is the difference between impersonation and delegation in OAuth token exchange?

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.

How impersonation changes the subject of the token

Impersonation is the more direct pattern: the exchanged token is presented so the downstream API treats the caller as the user or principal being impersonated. That can simplify integration when a service must act as a single visible actor, but it also means the receiving service has less context about which intermediary initiated the request and why.

The practical distinction is not just wording. In impersonation, the resource server typically sees the end principal as the effective actor, so the intermediary’s own identity is not the point of trust. In token-exchange terms, that makes the request look more like a direct call from the represented subject, which is useful for compatibility but weaker for audit clarity.

For the underlying token flow, the OAuth 2.0 standard and RFC 8693: OAuth 2.0 Token Exchange are the key reference points, because they define how one token can be exchanged for another with different semantics. Where the environment also depends on standard OAuth client behaviour, RFC 6749: The OAuth 2.0 Authorization Framework helps anchor the baseline grant and token model.

How delegation preserves who is acting and on whose behalf

Delegation keeps the intermediary visible. The resulting token carries evidence that one actor is acting on behalf of another, so the resource can distinguish the user or subject from the service that obtained or forwarded the token. That visibility is what makes delegation more useful when downstream accountability matters.

In practice, delegation is the stronger option when you need auditability, approval tracing, or policy decisions based on both the end user and the calling application. The receiving service can validate that the request is authorized for on-behalf-of use rather than simply accepting a token that makes the intermediary disappear behind the subject identity.

This is the same reason token exchange is often paired with sender-constraining or audience-restriction patterns in hardened deployments. If you want the delegation story to remain trustworthy, the token should be scoped tightly to the intended resource and protected from replay or misuse, which is where best-current-practice guidance for OAuth becomes relevant, especially around OAuth 2.0 security guidance and sender-constrained tokens.

When the difference matters in real systems

The choice affects observability, policy enforcement, and blast radius. Impersonation can be enough for a straightforward backend hop, but it can hide the calling system from logs and from authorization logic that should know which service initiated the request. Delegation is usually the better fit when a human or application must retain attributable responsibility across services.

That trade-off becomes important in distributed systems, especially where multiple services can exchange tokens, call APIs on behalf of users, or forward access through SaaS integrations. If the token model is too loose, the environment can drift into privilege confusion, token replay, or “who actually did this?” ambiguity after an incident.

For teams designing the surrounding controls, the best fit is often to combine delegation with audience restriction and proof-of-possession style protections so the token cannot be reused outside the intended path. If the system cannot preserve attribution, the safer default is usually to avoid impersonation for sensitive actions and require an explicitly delegated flow instead.

Risk and Threat Considerations

Token exchange becomes risky when a receiving service cannot reliably tell whether it is seeing the end user, the intermediary, or both. That ambiguity can weaken audit trails, mask abusive forwarding, and make overbroad tokens easier to replay across services.

Failure mechanism: Impersonation collapses the intermediary’s visibility, so a compromised or overly privileged service can obtain a token that looks like the user and use it beyond the original trust assumption.

Impact: Investigations become harder, privilege abuse is easier to miss, and an attacker who gains the intermediary can act with the user’s apparent authority instead of a clearly bounded delegated authority.

Practitioner Guidance

What to verify: Confirm whether the downstream API needs only the subject identity or also needs the calling application’s identity for authorization and logging. If the answer is both, delegation is usually the safer pattern.

What good looks like: The resource server can distinguish subject, caller, audience, and token purpose from the exchanged artifact alone, and logs preserve enough context to reconstruct who initiated the action.

Practitioner takeaway: Use impersonation only when hiding the intermediary is acceptable; use delegation when the system must preserve attribution, constrain abuse, and support defensible audit evidence.