Stackbook Logo
security-complianceemerging · medium operational burden

Token Exchange for Service-to-Service Calls

Also known as: rfc-8693, on-behalf-of-flow, token-downscoping

Intent

Swap an incoming token for a new one scoped to a specific downstream audience, preserving user context with minimal privilege.

Problem

Forwarding the user's original access token to every downstream service lets any compromised service replay it broadly. Using a shared service credential instead loses the identity of the end user.

Forces

  • •Downstream services need to know the user and the caller
  • •Tokens should be audience-restricted
  • •Privileges should shrink along a call chain
  • •Trust boundaries differ between internal and external domains

Solution

Overview

Token exchange lets a service ask the identity provider for a different token than the one it holds. It supports delegation (acting for a user) and impersonation, and is the standard answer to the confused deputy problem in microservice chains.

Many deployments use a gateway or mesh component as the exchanger so that application teams do not implement the grant themselves. Keep an allow-list of exchange rules as reviewable configuration, and log each exchange with subject, actor, audience and scopes to make investigations straightforward.

How it works

Client -> API Gateway: access token T1 (aud=gateway, scope=orders:rw)
Gateway -> STS: POST /token
   grant_type=urn:ietf:params:oauth:grant-type:token-exchange
   subject_token=T1  audience=billing  scope=invoices:read
   (authenticated as gateway client)
STS: policy(gateway may exchange for billing, read only)? yes
STS -> Gateway: T2 (aud=billing, sub=user, act=gateway, exp=2m)
Gateway -> Billing: T2

Each hop can exchange again, appending to the act chain for end-to-end traceability.

Pitfalls

  • Allowing any service to exchange for any audience.
  • Issuing exchanged tokens with scopes broader than the subject token.
  • Long lifetimes that defeat the point of narrow tokens. Use minutes.
  • Failing to cache exchanges per user and audience, causing load on the STS.
  • Downstream services ignoring aud or act.

Key takeaways

  • Never forward the original token across trust boundaries; exchange it.
  • Scopes only narrow, audiences are explicit, lifetimes are short.
  • Record the actor chain for audit.
  • Protect and scale the security token service like a core dependency.
  • Review key and token policies on a schedule, and alert on unusual access volume or new callers.
  • Run restore, rotation and failover drills so the control proves itself before an incident does.

✓ When to Use

  • •Microservices acting on behalf of a user
  • •Crossing trust domains or identity providers
  • •Narrowing broad edge tokens to per-service tokens

✗ When Not to Use

  • •Single monolith with no downstream hops
  • •Pure machine calls with no user context
  • •Where mTLS identity plus signed context headers suffices

Pros

  • +Audience-bound, least-privilege tokens
  • +Preserves user and actor identity for audit
  • +Limits replay value of stolen tokens

Cons

  • −Extra network hop per exchange
  • −Authorization server becomes hot dependency
  • −Policy for allowed exchanges is intricate

Cost Profile

Infrastructure

Medium — capable IdP

Operational

Medium — exchange policies

Cognitive

High

Failure Modes

  • Overly permissive exchange policy allows privilege escalation

  • Authorization server outage stalls all internal calls

  • Actor chain not validated, enabling confused deputy

Real-World Examples

Alternatives

    Related Patterns

      Competency Domains

      security compliancedistribution communication