Exchange purpose
Token exchange lets a client present a subject token, an actor token, or both to request a new security token for a target service. The new token can represent delegation or impersonation. Its authority, audience, type, and lifetime must be explicit.
Preserve the actors
The subject is the principal on whose behalf the action occurs. The actor is the current client or service. Keep both when they differ. Validate the incoming tokens, requester, issuer, audience, requested resource, requested token type, and policy before issuing the result.
Attenuate authority
Issue the smallest action set and shortest useful lifetime for the target audience. Do not copy every incoming scope or claim. The target resource server validates the exchanged token and performs local authorization on the exact resource and action.
Failure and residual risk
Exchange can expand authority, erase the originating actor, accept a token from the wrong issuer, or issue for the wrong audience. Token chains can outlive source revocation. A valid exchange can still create a confused deputy when the target cannot bind the caller's intent.
Pomerium boundary
Pomerium can preserve original request context for documented service-to-service flows and can enforce policy at each route. A separate authorization server can own standards-based token exchange. Upstream services must validate target credentials and authorize their own actions.
Evaluation checklist
- Are subject, actor, issuer, audience, resource, and token type explicit?
- Does the new token attenuate rather than copy authority?
- Can the target identify the originating subject and active actor?
- Does source revocation reach exchanged tokens within a measured time?
- Does the target perform local object and action authorization?
