Modern applications don’t run as a single monolithic. They are composed of services — frontend APIs, backend microservices, third-party integrations — each in its own security perimeter, potentially across different identity domains. The credentials that open one door don’t necessarily open another. 

OAuth 2.0 Token Exchange, defined in RFC 8693, is the standard that fills this gap. It gives a client a way to present an existing, valid security token to an authorization server and receive a different token in return, one that is scoped, shaped, and trusted for the next leg of the journey.

***RFC 8693 - CORE IDEA ****A client already holds a token. Rather than re-authenticating from scratch, it exchanges that token for a new one — potentially from a different issuer, with different scopes, representing a different identity relationship — all without exposing user credentials again.*

Think of it as a border crossing for tokens. Your passport gets you to the checkpoint. The checkpoint issues a temporary visitor's permit valid only for the area you're entering — not the whole country. Token exchange is that checkpoint, made programmable.

An API gateway sits at the intersection of every inbound request and every upstream service. It is, by design, the one entity in your architecture that sees all tokens, speaks to all services, and can be trusted to enforce cross-cutting policy.

Without token exchange at the gateway, each microservice has to solve the identity translation problem independently or worse, services get handed tokens that carry far more authority than they need. That's how privilege creep happens silently.

When token exchange lives in the gateway, three things become possible that were previously fragile or impossible:

✅ **Services stay dumb about identity complexity**: The gateway handles all token negotiation. A backend microservice receives exactly the token it expects with right scopes, right issuer and never needs to know what the original caller presented.

✅ **Trust boundaries are enforced in one place:** Policy about which tokens can be exchanged, under what conditions, for what scopes all live in gateway configuration, not scattered across ten services.

✅ **Cross-domain federation becomes tractable:** External tokens from a partner IdP, a third-party SAML provider, or a different internal domain can be translated into tokens the backend services actually understand at the edge, before any upstream service sees them.

**🔽 Downscoping**: A client or a service receives a broad, powerful token. Before calling an API or another service, exchange it for one scoped only to the permissions that operation requires. Least privilege, enforced automatically.

**🔄 Federation or Token Translation: **Client presents a token that is either opaque, SAML-based or from third-party IDP to the gateway. Exchange it for an internal JWT that the microservice actually understands. Translation happens once, at the edge.

**🔗 Delegation & Impersonation: **A front-end service needs to act on a user’s behalf when calling a back-end API. Exchange the front-end’s token for one that carries the user’s identity and only the scopes required from that specific back-end call.
**🔐 Privacy: **Strip the sensitive user claims from a token before forwarding it to a service that doesn’t need and shouldn’t see. PII stays where its needed and nowhere else.

Kong's implementation lives in the [**OpenID Connect plugin**](https://developer.konghq.com/plugins/openid-connect/)**OpenID Connect plugin**, which now supports token exchange for access tokens as of version 3.14. The plugin performs a strict sequence of checks before initiating any exchange, ensuring the token to be exchanged is valid and trusted before a new one is ever requested.

Validation checks before exchange triggers:

• - Issuer (iss claim) matches a configured allow list of token issuers
• - Token is not expired — exp claim verified
• - Token is not used before its valid time — nbf claim verified
• - Configured conditions (audience, scopes) are evaluated

Once those pass, Kong decides *whether* to exchange based on a simple but powerful rule: if the *original token issuer* and *target issuer* differ, exchange is always triggered. If they are the same IdP, the configured conditions determine whether exchange is warranted. Then Kong uses its own registered client credentials to execute the exchange with the authorization server.

• - **Subject Token**: The incoming token being exchanged. The "input" credential
• - **Subject Token Issuer**: The authorization server that originally issued the subject token
• - **Target Issuer**: The authorization server that should issue the new token for the upstream resource (original top-level issuer in the plugin)
• - **Conditions**: Rules (audience, scopes) that must be met to trigger an exchange
• - **Requested Token**: The output (or the new token issued after a successful exchange)

**How the flow moves**

Kong receives the subject token, validates it, applies configured conditions to decide whether exchange is warranted, and then uses its own client credentials to request a new token from the authorization server. The upstream service sees the exchanged one.

**Sam Issuer **| Conditions decide

The subject token and the target service both live under the same IdP (e.g., the same Keycloak realm). Exchange is not automatic. Kong evaluates the configured conditions. If the incoming token has a wide scope as matched against has_scope, exchange fires and token is exchanged for a narrower-scoped token.

*This is the pattern for downscoping within a single identity domain: the same issuer, but you want a tighter token for the next hop.*

**Different Issuers** | Exchange always triggers

The token came from an external partner IdP, a legacy SAML provider, or a different internal realm. The target service expects tokens from your own authorization server. Because the issuers differ, Kong automatically initiates the exchange. No additional conditions needed.

*This is the pattern for federation and external token translation: convert a foreign credential into a domestic one at the gateway boundary.*

Token exchange introduces a new attack surface: an actor that can trigger exchanges can potentially obtain tokens with different (even broader) authority than they started with. RFC 8693 is explicit about this: **trust models are not optional.**

*⚠️ ****The trust model must strictly define**** which clients are allowed to trigger exchanges, which subject token issuers are trusted, and what scopes or audiences can appear on an exchanged token. Misconfiguration here particularly overly permissive **subject_token_issuers **can open privilege escalation paths. Configure conditions narrowly.*

Kong's implementation guards against this by requiring an explicit list of subject_token_issuers (trusted issuers are eligible for exchange). The conditions layer (audience presence, scope presence) adds a second gate. And the exchanged token's scopes are determined by the request configuration, not by what the subject token claimed. The authorization server makes the final call if it will issue and on what it will actually issue.

Token exchange isn't a niche feature for complex enterprises. It's the logical conclusion of treating your API gateway as a ***security control plane***, not just a routing layer. As service meshes deepen, as partner integrations multiply, and as internal identity domains proliferate, the question of "whose token does this service trust, and what can it do?" becomes impossible to answer service-by-service.

Centralizing the answer in Kong (with RFC 8693 as the standard) and the OpenID Connect plugin as the mechanism means every upstream service can operate with a cleanly-scoped, correctly-issued token, regardless of how the original caller authenticated. The token it receives is the token it was designed to trust.

That's not a convenience. That's a security posture. 

Enhance your security posture with Kong. Start with Kong Gateway 3.14 by [signing up](https://konghq.com/products/kong-konnect/register)signing up for Kong Konnect for free. Or, if you want to try Kong Gateway Enterprise 3.14, you can explore the options for getting started [here](https://konghq.com/install)here.

To explore the comprehensive list of features, fixes, and updates, please see the available CHANGELOG for Kong Gateway Enterprise [here](https://docs.konghq.com/gateway/changelog/)here.