Learning outcomes
- Distinguish delegation, impersonation, service authority, and user identity.
- Preserve the originating actor and each deputy across an access chain.
- Bind delegated authority to a resource, action, audience, and lifetime.
- Detect identity collapse, token passthrough, and confused-deputy failures.
Protection need
A service or agent often acts because a human, workload, or earlier service requested an action. The target must know which principal owns the resource, which actor is executing, what authority was delegated, and which service audience may accept it. Collapsing these identities hides accountability and expands authority.
Security objectives and requirements
Represent at least the originating subject, active actor or client, target resource, audience, permitted actions, delegation chain, issue and expiry times, and policy basis. Distinguish:
- Delegation: An actor receives limited authority to act for a subject.
- Impersonation: The actor is presented as the subject, often hiding the actor.
- Service authority: A workload acts for itself, not for a user.
- Identity propagation: A verified identity fact is carried downstream without granting all of that identity's authority.
Exchange broad incoming credentials for narrow target credentials when possible. Each target validates the credential and repeats local authorization.
Security invariants and evidence
- Every hop retains the originating subject and active actor.
- A credential is valid only for its intended resource audience.
- Delegated actions are no broader than the source grant and current policy.
- The target can reject a valid delegation that lacks local permission.
- Evidence can reconstruct the full chain without storing bearer credentials.
Failure cases
- A service forwards an incoming bearer token to an unintended downstream.
- A shared service token makes every caller indistinguishable.
- Token exchange removes the original subject or actor.
- A tool inherits all user authority for one narrow task.
- A delegated credential is accepted by a different resource server.
- A revoked user remains able to act through an unexpired deputy credential.
Design tradeoffs and residual risk
Explicit delegation improves control and evidence but adds token, policy, and lifecycle complexity. Short-lived credentials reduce exposure but increase dependency on exchange services. Long chains improve attribution but can reveal sensitive relationships and become hard to validate.
Limit chain length, accepted issuers, audiences, actions, and lifetime. Define how revocation reaches each derived credential.
Pomerium boundary
Pomerium can authenticate the incoming user, enforce route policy, and pass verified identity context to an upstream. It does not automatically create a target-specific delegated credential for every downstream API. The application and authorization server must preserve actor semantics and constrain downstream authority.
Exercise
Model a user asking an agent to call a billing API through two services. Record the subject, actor, credential, audience, action, policy, expiry, and evidence at each hop. Then test wrong audience, broader action, missing actor, revoked subject, and direct token passthrough.
Evaluation checklist
- Can the target identify both the originating subject and current actor?
- Is each credential restricted to an intended audience, action, and lifetime?
- Does exchange attenuate authority instead of copying it?
- Can revocation stop derived authority within a measured time?
- Can evidence reconstruct the chain without exposing credentials?
Next learning unit
Confused Deputy
Prevent a service or agent from using its own authority for a caller that did not have permission to request the action.
