Notifications
Clear all
Topic starter
24/06/2026 7:24 pm
TL;DR: OAuth 2.0 Token Exchange changes how services translate trust across domains, letting gateways reissue scoped tokens for downstream calls instead of forwarding broad credentials, according to Kong. That makes gateway policy a core identity control, not just routing logic, because privilege creep and federation risk now converge at one enforcement point.
NHIMG editorial — based on content published by Kong: Token exchange at the gateway and how OAuth 2.0 reshapes trust between services
By the numbers:
- Kong says its OpenID Connect plugin supports token exchange for access tokens as of version 3.14.
Questions worth separating out
Q: How should security teams implement token exchange in API gateways?
A: Security teams should implement token exchange as a policy-controlled identity translation step, not as a convenience feature.
Q: When does token exchange create more risk than it reduces?
A: Token exchange creates more risk when the trust model is vague, issuer lists are too broad, or scope rules are permissive.
Q: What do teams get wrong about gateway-based federation?
A: Teams often treat federation as a token format problem instead of a trust problem.
Practitioner guidance
- Define issuer trust narrowly Maintain an explicit allow list of subject token issuers and review it as a governance asset, not a routing setting.
- Constrain exchange by audience and scope Require audience and scope checks before any token is exchanged, then verify that the requested token is narrower than the subject token for the downstream task.
- Map each exchange flow to a business use case Separate downscoping, federation, and delegation flows so each has a documented justification, owner, and audit trail.
What's in the full article
Kong's full article covers the operational detail this post intentionally leaves for the source:
- The exact OpenID Connect plugin checks used before exchange, including issuer, expiry, not-before, and configured conditions.
- The same-issuer versus cross-issuer decision flow that determines when exchange is triggered automatically.
- Concrete configuration concepts such as subject token, target issuer, and requested token for implementation teams.
- The gateway-side trust model considerations that define which clients may request exchanges and under what conditions.
👉 Read Kong's analysis of OAuth token exchange at the gateway →
Token exchange at the gateway: what it means for IAM teams?
Explore further
25/06/2026 4:40 am
Token exchange exposes a trust translation gap, not just a protocol feature gap. The architectural issue is that service-to-service trust no longer ends at authentication. It now depends on whether the intermediary can safely reshape authority before the next hop. That matters because broad upstream tokens often survive longer than the business context that justified them, and downstream services then inherit privilege they were never meant to see. Practitioners should treat token exchange as part of the trust boundary, not an add-on to it.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to The State of Secrets Sprawl 2026.
A question worth separating out:
Q: Who is accountable when a token exchange policy allows excessive access?
A: Accountability sits with the team that owns the gateway policy and the identity trust model, not only with downstream service owners. If the exchange configuration allows excessive access, the control failure is in issuer trust, scope definition, or governance review. The gateway is the decision point and must be managed as such.
👉 Read our full editorial: Token exchange at the gateway reshapes service trust and privilege
