You're building a microservices architecture and need to make authorization decisions across trust boundaries. Token exchange keeps coming up in design discussions, but you're facing the same question every team asks: will this add unacceptable latency to our critical path?
The decision isn't binary. The right answer depends on your traffic patterns, your tolerance for added hops, and what you're actually protecting. Here's how to make the right choice.
The Decision You're Facing
You need to authorize service-to-service calls in a distributed system. Your options:
- Direct trust: Services trust each other's tokens without exchange.
- Token exchange: Services swap tokens through a central authorization server.
- Hybrid: Exchange only at specific boundaries.
Each path trades off security isolation against request latency. The question is which trade makes sense for your workload.
Key Factors That Affect Your Choice
Your traffic profile. If you're processing 50 requests per second, a 10-millisecond exchange adds 500 milliseconds of aggregate latency per second to your system. If you're at 500 per second, that same exchange consumes 5 seconds of latency budget per second across all requests. The absolute number matters less than the ratio to your capacity.
Your trust boundaries. Token exchange makes sense when you need cryptographic proof that a specific service is acting on behalf of a specific user for a specific resource. If your services already run in the same security zone with mutual TLS and you trust them equally, exchange adds ceremony without value.
Your infrastructure headroom. A controlled test on a two-engine PingFederate cluster running on Amazon EKS with r5.xlarge instances achieved a p95 latency of 9.5 milliseconds at 500 exchanges per second with zero failures. CPU consumption scaled approximately linearly, consuming about 5 CPU-milliseconds of aggregate engine CPU per completed exchange. That's the floor; your production environment will add network hops, policy evaluation, and external dependencies.
Your failure tolerance. Token exchange introduces a synchronous dependency on your authorization server. If that server is unavailable, exchanges fail. Direct trust fails only when the target service is down. You're trading a single point of failure for stronger isolation.
Path A: Choose Direct Trust When
You operate within a single trust domain. If all your services run in the same Kubernetes namespace, share the same security controls, and are maintained by the same team, token exchange is overhead. Validate the incoming token's signature and claims, then proceed.
Specific conditions:
- Services authenticate with mutual TLS.
- All services share the same threat model.
- You're willing to accept that a compromised service can impersonate any user to any other service.
- Your compliance framework doesn't require audience-restricted tokens.
What you gain: Sub-millisecond authorization decisions. No central bottleneck. Simpler failure modes.
What you lose: A compromised service can mint tokens for any resource. You cannot enforce resource-level audience restrictions without rebuilding them in every service.
Path B: Choose Token Exchange When
You're crossing trust boundaries. If Service A in the orchestration layer needs to call Service B in the data layer on behalf of a user, and those layers have different risk profiles, exchange enforces that the token Service B sees is scoped to Service B's resource URI.
Specific conditions:
- You're implementing RFC 8693 token exchange with audience restriction.
- Your authorization server can handle your peak exchange rate with acceptable latency (test this, the 9.5-millisecond p95 at 500 exchanges per second is a reference point, not a guarantee).
- You need the
actclaim to track delegation chains. - Your compliance requirements demand proof of authorized delegation.
What you gain: Cryptographic audience restriction. Every token is scoped to exactly one resource. You can audit the full delegation chain through act claims.
What you lose: Every exchange adds latency. At 500 exchanges per second with 5 CPU-milliseconds per exchange, you're consuming 2.5 CPU cores on aggregate engine capacity. Scale your authorization infrastructure accordingly.
Path C: Choose Hybrid Segmentation When
You need exchange at specific boundaries but not everywhere. Run direct trust within security zones and exchange only when crossing zone borders.
Specific conditions:
- Your architecture has clear trust boundaries (e.g., frontend zone, backend zone, data zone).
- Traffic within a zone is high-volume and latency-sensitive.
- Traffic crossing zones is lower-volume and can tolerate the exchange hop.
- You can enforce the boundary with network policy or service mesh rules.
Implementation pattern: Services within a zone accept tokens issued to any service in that zone. Services at the zone edge perform token exchange before calling into the next zone. The exchange rewrites the audience claim to match the target zone's resource URI.
What you gain: Exchange overhead only where it matters. Lower aggregate CPU consumption. Simpler failure analysis within zones.
What you lose: More complex policy management. You must maintain two authorization models and ensure the boundary enforcement is watertight.
Summary Matrix
| Factor | Direct Trust | Token Exchange | Hybrid |
|---|---|---|---|
| Latency | < 1 ms | 5-10 ms p95 | Mixed |
| CPU cost | Negligible | ~5 CPU-ms per exchange | Zone-dependent |
| Blast radius | Zone-wide | Service-scoped | Zone + boundary |
| Compliance fit | Weak | Strong | Moderate |
| Operational complexity | Low | Medium | High |
The numbers matter, but the architecture matters more. Measure your actual exchange latency under load before committing to a path; the 9.5-millisecond figure is a reference point from a controlled test, not a universal constant. Your mileage will vary with your policy complexity, your network topology, and your authorization server's configuration.
Choose the path that matches your threat model, not the one that sounds most sophisticated.
