Token exchange at the gateway reshapes service trust and privilege

At a glance

What this is: This is an analysis of OAuth 2.0 token exchange at the API gateway and its role in translating trust between services.

Why it matters: It matters because IAM teams now have to govern token translation, issuer trust, and privilege scoping at the gateway, not only at each backend service.

Context

Modern service architectures often need one identity to be translated into another before a downstream call is made. That problem becomes an IAM issue when broad credentials travel too far, or when services receive tokens issued for a different trust domain. Token exchange addresses that gap by changing the credential presented at the boundary.

Kong frames the API gateway as the enforcement point for that translation because it sees inbound tokens, upstream services, and cross-domain policy in one place. The governance question is no longer only whether a request is authenticated, but whether the token handed to each service is appropriately scoped for that service's own trust boundary.

Key questions

Q: What breaks when token exchange is allowed without tight issuer and audience controls?

A: The exchange path can become a privilege escalation mechanism. A valid token may be translated into a different token with broader reach than intended, especially if the gateway trusts too many issuers or permits too many audiences. The control failure is usually policy scope, not token validation itself.

Q: Why does token exchange increase governance risk in service-to-service architectures?

A: Because the system is no longer only checking whether a caller is authenticated. It is also deciding how authority changes between hops, which means a misconfigured gateway can redefine downstream trust boundaries. That is why token exchange has to be governed as an authorisation control.

Q: How can security teams tell whether gateway-based token exchange is working as intended?

A: Look for exchanged tokens that are narrower than the incoming credential, issued only for approved audiences, and accepted only from authorised issuers. If downstream services still receive broad or foreign tokens unchanged, the control is not operating as designed.

Q: What is the difference between token validation and token exchange at the gateway?

A: Token validation checks whether a presented token is authentic, unexpired, and trusted. Token exchange goes further by replacing that token with a new one that is specifically shaped for the next service or trust domain. Validation answers whether the caller can be trusted; exchange answers what authority the next hop should receive.

Technical breakdown

How OAuth 2.0 token exchange changes service-to-service trust

OAuth 2.0 token exchange, defined in RFC 8693, lets a client present one valid security token and receive another token that is meant for a different trust context. In practice, that means the original credential does not have to travel unchanged through every hop. Instead, the system can issue a new token with its own issuer, audience, and scopes. That is especially useful when frontends, internal microservices, partner integrations, and legacy identity domains all participate in the same request path.

Practical implication: Treat token exchange as a control for trust translation, not a convenience feature for authentication reuse.

Why the gateway is the control point for scoped delegation

An API gateway is the natural place to apply token exchange because it already sits at the boundary between callers and services. It can validate the incoming token, check issuer trust, evaluate conditions such as audience and scopes, and request a new token before any backend receives the call. This centralises policy that would otherwise be duplicated across services, reducing the chance that individual services accept broader authority than they need. It also makes delegation and impersonation patterns easier to govern because the downstream token is shaped once at the edge.

Practical implication: Centralise exchange rules in the gateway so downstream services only see tokens they are meant to trust.

Where token exchange can create privilege escalation paths

Token exchange introduces a new governance risk if the trust model is too loose. A client that can trigger exchange may obtain a token with different authority from the one it started with, so the allowed issuers, scopes, and audiences have to be tightly constrained. If subject token issuers are overbroad, exchange can become a privilege escalation path rather than a scoping control. The key failure is not the standard itself, but the assumption that any valid token should be exchangeable into any other useful token.

Practical implication: Define issuer allow lists and exchange conditions narrowly before allowing downstream token translation.

Breaches seen in the wild

• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Token exchange turns the gateway into an identity enforcement point, not a routing layer. Once a gateway is responsible for reissuing scoped tokens, it is participating in authorisation design as well as traffic control. That means policy errors at the edge can shape downstream privilege across multiple services, so gateway governance becomes part of IAM governance.

Gateway token translation exposes the trust boundary that service meshes often obscure. Microservices frequently assume the token they receive is already the right token for their domain. Token exchange makes that assumption explicit by separating the caller's credential from the service's trust requirement, which is exactly why policy needs to be centralised.

Privilege creep is easier to hide when credentials are forwarded unchanged. Broad tokens passed hop by hop make it hard to see where authority should have been reduced. Exchange at the gateway creates a named control point for downscoping, which gives practitioners a place to audit issuer trust, audience scope, and delegation intent.

Trust models must now be designed around token mutation, not just token validation. RFC 8693 allows one valid token to become another token with different claims and different reach. That means access governance has to evaluate what the exchanged token can do, not only whether the original token was authentic.

Scoped delegation is the right mental model for gateway-based exchange. The important outcome is not simply that a service can call another service. The important outcome is that each service receives a token whose authority matches the specific leg of the journey, which is the point at which least privilege becomes operational rather than theoretical.

What this signals

Scoped delegation becomes the real control objective: gateway policy should shape what each downstream service is authorised to receive, not just whether the original token is syntactically valid. That shifts design attention from authentication success to trust translation quality.

Token exchange also exposes a programme question that many IAM teams have avoided: where does authority get reduced, and who owns that decision? If the answer is scattered across services, privilege creep is likely to reappear in a more distributed form.

For practitioners

• Define exchange trust boundaries List which subject token issuers are trusted, which clients may trigger exchange, and which downstream audiences are permitted for each route.
• Enforce downscoping at the gateway Require exchanged tokens to carry only the scopes needed for the next service call, not the scopes held by the original caller.
• Audit cross-domain delegation paths Map every place where an external token, SAML assertion, or different internal issuer can be translated into an internal access token.
• Review gateway policies for escalation risk Check whether any exchange rule could widen authority when issuers differ, conditions are too broad, or audience checks are weak.

Key takeaways

• Token exchange at the gateway is fundamentally an authorisation design pattern, because it changes how trust is translated between identity domains.
• The key governance risk is overbroad exchange policy, which can turn a valid token into a wider downstream privilege than the caller should have.
• IAM teams should treat issuer allow lists, audience constraints, and downscoping rules as gateway controls, not as backend implementation details.

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.
• Subject Token: The incoming token presented for exchange. It is the credential that proves the caller already has some valid authority, but it may be too broad, too foreign, or too sensitive to forward unchanged to the next service or domain.
• Join Token: A join token is the policy object that governs how a machine or workload is allowed to exchange its runtime identity for downstream access. For CI/CD, it acts as the gatekeeper between attested job claims and the ability to receive a certificate or session credential.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.

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 building or maturing an IAM programme, it is worth exploring.