Advanced20 min

Delegated Authorization

Acting on behalf of someone else — on-behalf-of, token exchange, and the confused deputy.

By the end of this lesson, reason about delegation chains and prevent confused-deputy and privilege-escalation bugs.

How deep?
How the pieces actually move.

Real systems are chains: a user calls a gateway, which calls a service, which calls a database. Whose authority applies at the end? Delegated authorization is how a component acts on behalf of another principal while preserving — and bounding — the original authority.

First, the whole system

First, see the whole system. Then we’ll open it up.

On-behalf-of token exchange

On-behalf-of token exchange

  1. A gateway receives the user's token and exchanges it at the authorization server for an on-behalf-of token.
  2. The new token names the user as subject and the gateway as actor, scoped down.
  3. The downstream service decides using the user's authority, not the gateway's.
flowchart LR
  user[User token] --> gw[Gateway / BFF]
  gw -->|exchange: act for user, scoped| as[Authorization server]
  as -->|OBO token: sub=user, act=gw| svc[Downstream service]
  svc -->|decision uses user's authority| db[(Resource)]
Token Exchange (RFC 8693)
A standard for swapping one token for another — narrowing scope, changing audience, or adding an act (actor) claim to record 'A acting for B'. The basis for on-behalf-of flows.
Abstraction leak

This is where the abstraction starts leaking.

The confused deputy is the signature failure here: a privileged component performs an action using *its own* authority because a less-privileged caller asked it to, without checking whether the caller was allowed. Server-side request forgery and many IAM escalations are confused deputies. The deputy must act with the *caller's* authority, not its own.

Now break it

An internal 'export service' has admin DB access and exports whatever record ID you pass it. A low-privilege user passes an admin's record ID. The export service happily uses its own admin rights. That's a confused deputy — what check is missing?

Confused deputy

Trigger
A privileged service acts on a caller's request using its own authority without verifying the caller's.
Symptom
Low-privilege callers reach data/actions only the deputy should.
Blast radius
Privilege escalation up to the deputy's full authority.
Mitigation
Propagate and enforce the caller's authority (OBO tokens); check authZ against the original subject.

Deep dive: Privilege Escalation

Blast radius

Narrowing authority at each delegation hop shrinks blast radius but adds token-exchange round trips and policy complexity. Passing the original broad token everywhere is simpler and far more dangerous — one compromised hop has full rights.

How does delegation differ from impersonation in the token?

Delegation records both parties (sub=user, act=service) preserving the chain; impersonation drops the actor so only the user appears.

Delegation decides whose authority is used. But something must actually evaluate the request against policy. Where does that happen?

Next: Policy Enforcement →