On-Behalf-Of Authorization Flow¶
Token-exchange protocol — instantiates Principal-Bound Authority Mediation
Exchanges an incoming user credential for a downstream one that still represents the original caller, so each service hop re-derives authority from the real principal instead of falling back on its own broad service account.
In a chain of services, the lazy path is for each hop to call the next with its own standing credential — and that is exactly how the caller's identity evaporates and a downstream service ends up trusting an intermediary's broad power. On-Behalf-Of Authorization Flow is the protocol that refuses that path. Instead of forwarding its own service identity, a middle service takes the credential it received from the caller and exchanges it at the identity provider for a new credential that still names the original principal, marked as issued on behalf of that caller. The defining move is that authority is re-derived from the real requester at every hop rather than assumed from the deputy's standing account — the deputy is deliberately kept from spending its own broad power, and the caller's provenance is threaded through the whole call chain.
Example¶
A SaaS build platform runs a deployment service that, when an engineer triggers a pipeline, must read the engineer's source bucket and write to their project's database. Both back-end APIs are multi-tenant and privileged. The dangerous design has the deployment service call them with its own platform-wide credential — a confused deputy that could touch any tenant's data. The on-behalf-of flow rewires it: the engineer's pipeline hands the deployment service a token representing the engineer; the service presents that token to the identity provider and receives back a new token scoped to the storage and database APIs but still stamped acting on behalf of engineer j.okafor in tenant acme.
Storage and database receive that on-behalf-of token, not the deployment service's blanket credential. Each evaluates the request as the engineer's — so a pipeline for tenant acme cannot read tenant globex's bucket, because the propagated identity, not the deputy's reach, decides. If the deployment service were compromised and tried to call storage with its own broad account, storage would see an ambient service credential where it now demands a caller-derived one, and refuse. The engineer's authority, not the deputy's, flows to the point of action.
How it works¶
- Receive the caller's credential. The middle service starts from the token it was given by the upstream principal, not from its own identity.
- Exchange it for a delegated one. It presents that token to the identity provider and asks for a new token, scoped to the next hop, that continues to represent the original caller as the acting principal.
- Constrain the deputy's own authority. The service is barred from substituting its standing account for the exchanged token; its broad credential is not an accepted input to sensitive downstream calls.
- Re-evaluate at each hop. Every downstream service authorizes against the propagated caller identity, so authority is checked afresh against the real requester rather than inherited through service trust.
Tuning parameters¶
- Exchange depth — how many hops re-derive the caller identity. Full-chain propagation closes every gap but multiplies token exchanges and latency; stopping early leaves an ambient-trust segment.
- Downstream scope narrowing — how tightly the exchanged token is scoped to the next hop's needs. Narrower limits blast radius but requires the exchange to know the intended audience.
- Token lifetime on exchange — short-lived delegated tokens reduce replay exposure but add refresh traffic under long-running pipelines.
- Fallback stance — whether a service may ever use its own credential when no caller token is present. Forbidding it entirely is safest but breaks genuinely un-attributed background jobs that then need their own design.
- Trust boundary for exchange — which services are allowed to request on-behalf-of tokens at all. Restricting the privilege prevents a low-trust hop from minting delegated authority it should only forward.
When it helps, and when it misleads¶
Its strength is that it kills the archetype's most common failure — ambient service-account fallback — by construction: a downstream call that isn't on behalf of a real caller simply doesn't carry the credential it needs. It lets middle services stay operationally useful without becoming authority-laundering channels, and because identity is re-derived per hop, cross-tenant reach through a broad deputy is closed off. It is the standard pattern where a service must act as its users across an API chain.[1]
Its failure modes come from the exchange being intricate. A single hop that forgets to exchange — and calls downstream with its own account "just this once" — silently reopens the confused-deputy hole, and these gaps are easy to miss because everything still works. Over-broad scope on the exchanged token, or an over-long lifetime, dilutes the benefit; and the flow adds real latency and operational surface that tempt teams to shortcut it. The guarding discipline is to forbid ambient-credential downstream calls outright on sensitive paths, keep exchanged tokens narrow and short-lived, and test specifically for the hop that skips the exchange.
How it implements the components¶
deputy_execution_authority— it treats the deputy's standing credential as a constrained resource that must not be spent on sensitive downstream calls, forcing action under the caller-derived token instead.ambient_authority_exclusion— a service's own broad account is explicitly excluded as an input to downstream authorization; only the exchanged on-behalf-of credential is accepted.request_provenance_trace— the original caller is propagated and re-asserted at each hop, threading the requester's identity through the whole chain rather than losing it after the first service.
It does not package the delegation as a signed, self-contained artifact carrying fixed scope and freshness — that request_intent_scope and delegation_context_record bundling is its nearest twin Signed Delegation Token's job; this mechanism is the live exchange protocol, the twin the credential it moves.
Related¶
- Instantiates: Principal-Bound Authority Mediation — supplies the per-hop re-derivation of authority from the real caller across a service chain.
- Consumes: Signed Delegation Token — the exchanged credential it forwards is typically a signed delegation token.
- Sibling mechanisms: Signed Delegation Token · Policy-Engine Subject Binding Check · Scoped Service-Account Impersonation · Object-Capability Reference · Delegation Audit Log · Confused-Deputy Abuse-Case Test · CSRF Token Challenge · Origin and Referer Gate
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: The mechanism automatically exchanges an incoming user credential for a narrower downstream token that preserves the original principal on each service hop.
Nearest alternative: Protocol, Workflow & Routine — The exchange follows an ordered protocol, but the concrete deployed form is a live authorization component acting on runtime requests.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Distributed-systems security developed delegated token exchange, including OAuth 2.0 Token Exchange and on-behalf-of flows that preserve the initiating principal across service hops.
Related originating lineages:
- Security Studies & Intelligence Analysis — Principal-bound delegation and least-authority doctrine supply the threat model against broad deputy credentials.
Review resolution: Both independent reviews agree on primary origin computer_science; reconciliation resolves alternate_origin_disagreement. Formative alternate lineages retained: security_intelligence. The broader reach of later applications is kept separate as domain_reach=specialized; origin_mode=single_lineage describes the historical relationship among lineages. Confidence is conservatively reconciled to high, and encyclopedia_synthesis=false preserves the reviewers' boundary judgment.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] OAuth 2.0 Token Exchange (RFC 8693) standardizes swapping one security token for another, including delegation semantics that mark a token as issued on behalf of a subject. Microsoft's Azure AD "On-Behalf-Of flow" is a widely-deployed instance, letting a middle-tier API call downstream APIs as the signed-in user rather than as itself. registry ↩