Token exchange at the gateway reshapes service trust and privilege

At a glance

What this is: Kong argues that OAuth 2.0 Token Exchange shifts trust translation into the API gateway so downstream services receive purpose-scoped tokens instead of overbroad upstream credentials.

Why it matters: For IAM, NHI, and platform teams, this matters because token brokering, downscoping, and federation decisions now sit at the boundary where service identity, privilege, and trust are actually enforced.

By the numbers:

• Kong says its OpenID Connect plugin supports token exchange for access tokens as of version 3.14.

👉 Read Kong's analysis of OAuth token exchange at the gateway

Context

OAuth 2.0 token exchange is a way to swap one valid token for another that is better suited to the next service hop. In identity terms, it solves the gap between the credential a caller already has and the narrower authority the downstream service should accept.

The governance problem is not authentication alone, but how trust is translated across APIs, microservices, and external identity domains. Without a controlled exchange point, services either inherit too much privilege or recreate token-handling logic on their own, which makes policy drift more likely.

For IAM and NHI programmes, the gateway becomes an identity boundary as much as a traffic boundary. That puts issuer trust, audience scoping, and delegation rules into the same control plane that already mediates service access, which is where many programmes have been missing enforcement depth.

Key questions

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. The gateway should validate issuer, expiry, audience, and scope before any exchange occurs, then issue a downstream token that is narrower than the original. Keep the allowed issuers list explicit and review it regularly.

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. In that case, the gateway can amplify privilege instead of constraining it. The safe boundary is one where every exchange has a documented purpose and a clearly narrower downstream authority.

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. The real issue is whether the gateway can safely translate a foreign identity assertion into a local token without exposing broader access than the downstream service needs. If policy is inconsistent, the translation layer becomes a privilege gap.

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.

Technical breakdown

OAuth 2.0 token exchange as scoped identity translation

OAuth 2.0 Token Exchange, defined in RFC 8693, lets a caller present an existing security token and receive a different token for a new trust context. The important technical shift is that the subject token is not reused as-is. It is evaluated, then exchanged for a requested token with different scopes, issuer expectations, and audience constraints. This avoids forwarding a broad upstream token into a downstream service that should only see a narrower authority set. In practice, the gateway becomes the place where trust is reshaped before the call continues.

Practical implication: place exchange logic where token scope can be validated once and reused consistently across service hops.

Why the API gateway is the enforcement point for token exchange

An API gateway sees inbound requests, upstream destinations, and the policy needed to reconcile them. That makes it the natural control point for token exchange because it can validate issuer, expiry, not-before, audience, and scope conditions before any new token is requested. Kong describes a sequence in which the original token is checked first, then exchange is triggered only when configured conditions are met or when issuers differ. This centralises trust decisions that would otherwise be duplicated across services and exposes them to one policy layer instead of many.

Practical implication: enforce issuer allow lists and exchange conditions at the gateway, not in individual services.

Downscoping, federation, and delegation all depend on the same control

Token exchange supports three common production patterns. Downscoping trims a broad token before a sensitive operation. Federation translates a foreign or opaque token into one the local resource server understands. Delegation lets a front-end act on behalf of a user without passing user credentials through every layer. The common requirement is that the downstream service receives the token it is designed to trust, not the one the original client happened to hold. That is what makes token exchange a security control rather than a convenience feature.

Practical implication: define which exchanges are allowed by use case, then test whether each downstream service truly needs the translated token it receives.

NHI Mgmt Group analysis

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.

Gateway-centralised exchange reduces privilege creep, but only if issuer and audience policy is explicit. The article makes clear that the danger is not exchange itself, but exchange without constrained trust rules. When subject token issuers are too broad or conditions are too loose, the gateway becomes a privilege amplification point. This aligns with OWASP NHI guidance on controlling token scope and with zero trust expectations that access decisions be contextual and narrowly bounded. The practitioner takeaway is that gateway policy must define what can be exchanged, not merely whether exchange is enabled.

Cross-domain federation is now an identity design problem, not a back-end implementation detail. The more services span partner IdPs, internal realms, and legacy token formats, the more valuable a single translation point becomes. But that also means architectural trust is being concentrated in the gateway, where misconfiguration can affect every upstream call. IAM teams should treat this as a control-plane decision that needs governance, review, and auditability, because service teams cannot safely improvise token translation independently.

Token exchange makes the gateway part of the identity control plane for machine access. That is the named concept this article sharpens. The practical implication is that service tokens, delegation rules, and federation choices should be governed like identity policy, not merely like API configuration. Once token exchange becomes the standard path between domains, the gateway inherits responsibility for shaping machine trust at runtime.

From our research:

• 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.
• For the governance layer that sits above token handling, see Guide to the Secret Sprawl Challenge for how secret lifecycle controls change when credentials move across pipelines and service domains.

What this signals

With 64% of valid secrets from 2022 still exploitable today, the larger lesson for identity teams is that translation controls matter only when the underlying trust material is also governed across its lifecycle. Token exchange can narrow privilege at runtime, but it does not fix stale credentials or broken revocation habits upstream.

Identity translation debt: when one service passes trust to another without a durable policy model, the organisation accumulates hidden authority that is hard to audit later. That is why gateway-based federation should be tied to the same governance discipline used for privileged accounts and workload identities.

For teams already working on federation and service identity, the next step is to pair gateway policy with workload identity standards such as the NIST AI Risk Management Framework where AI-mediated access paths are involved, and with token trust reviews for every domain boundary.

For practitioners

• Define issuer trust narrowly Maintain an explicit allow list of subject token issuers and review it as a governance asset, not a routing setting. Limit exchange eligibility to the smallest set of trusted identity domains that actually need it.
• 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. That prevents token exchange from becoming an undifferentiated pass-through for privilege.
• Test the gateway as an identity boundary Validate that services receiving exchanged tokens can only act within the scopes they were designed to trust. Include negative tests for overbroad issuer acceptance and unintended scope expansion.

Key takeaways

• OAuth token exchange moves trust translation into the gateway, which changes where privilege must be governed.
• The main risk is not exchange itself, but overly broad issuer and scope policy that can amplify access instead of reducing it.
• Practitioners should treat token exchange as a control-plane decision, with explicit trust rules, auditability, and lifecycle review.

Key terms

• OAuth 2.0 Token Exchange: OAuth 2.0 Token Exchange is a standard that lets one valid token be swapped for another token suited to a different trust context. In practice, it allows a gateway or authorization server to reduce scope, change issuer expectations, or translate identity between domains without forwarding the original credential.
• Downscoping: Downscoping is the practice of issuing a token with fewer privileges than the caller originally held. It is used when a service only needs a narrow subset of authority, and it helps reduce the blast radius of a token if it is later exposed or misused.
• Issuer Trust List: An issuer trust list is the set of token issuers that a gateway or authorization server is willing to accept as valid origins for exchange. In identity governance, it is a critical control because overly broad issuer acceptance can turn a translation layer into a privilege escalation path.
• Identity Control Plane: An identity control plane is the policy layer that decides how identities are validated, translated, and authorised across services. For machine and service identities, it is where trust, scope, delegation, and lifecycle rules are enforced consistently instead of being recreated inside each application.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: Token exchange at the gateway and how OAuth 2.0 reshapes trust between services. Read the original.