Token exchange at the gateway: what it means for IAM teams

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

View Full Forum →  |  NHI Foundation Course →