# Token exchange and ID-JAG > How the gateway's Security Token Service uses RFC 8693 OAuth 2.0 Token Exchange and ID-JAG to carry an already-verified identity across a gateway or service boundary, without a fresh sign-in at every hop. An agent that has already proven its identity to one gateway or service often needs to call a second, unrelated service downstream, one that never saw the original sign-in and has no way to confirm who the agent actually is. Re-authenticating at every hop is not always possible, and asking the downstream service to trust the first system outright creates a direct trust dependency that neither side may want. A token exchange lets an agent, or a service acting for one, swap a token it already holds for a new token scoped to a different, specific downstream audience, without repeating the original authentication. The gateway’s Security Token Service (STS) implements this using RFC 8693 OAuth 2.0 Token Exchange: a registered STS Client presents a token proving an already-verified identity and receives one narrowed to the exact audience and scopes it needs next, gated by the same policy engine that governs proxied requests. Identity can then cross a gateway or service boundary without a fresh sign-in at every hop, and without the receiving side having to trust the sending system directly. [Create an STS Client →](/products/affinidi-trust-fabric/agent-gateway/reference/authentication/sts-clients.md) ## Why it exists In a deployment with more than one boundary, whether that is two gateways, or a gateway and an external OAuth-protected service, an agent’s proof of identity is normally only good for the system that issued it. A token minted for one audience does not, by itself, prove anything to a second audience with its own separate token endpoint. Without a standard way to carry that proof forward, the choices are limited: repeat the original authentication at every hop, which is not possible for identity sources that have no interactive login step, such as a payload-derived identity or an mTLS certificate scoped to one connection (see [Agent identity and DIDs](/products/affinidi-trust-fabric/agent-gateway/concepts/identity.md) for how those identities are established); or have the downstream service accept whatever the upstream system asserts, with no independent way to check it. Token exchange gives the gateway a standards-based alternative. RFC 8693 defines exactly how one token is traded for another, so any RFC 8693-compliant resource server, not only another instance of the gateway, can participate without a custom integration. ## How a token exchange works A client authenticates to the gateway’s token endpoint with its Client ID and secret, then presents a subject token: a JWT, ID Token, ID-JAG, or Verifiable Presentation proving an identity that was already verified somewhere. It states which audience and scopes it wants the new token scoped to. The gateway checks the subject token’s type and audience against what this client is allowed to present, checks the requested audience and scope against what this client is allowed to request, runs the exchange through the same policy engine that governs proxied requests, and only then mints a new, narrower token. The issued token can carry an RFC 8693 delegation chain, the act claim, recording who acted on whose behalf. When the client supplies its own actor token alongside the subject token, that actor becomes the current entry in the chain, nested above whatever chain the subject token already carried. When it does not, and impersonation is not explicitly allowed for that client, the gateway records the client itself as the delegating actor, so the issued token still carries a trace of who requested it rather than looking exactly like a token the subject obtained directly. ## How ID-JAG hands off identity without a full access token Requesting an ID-JAG (Identity Assertion JWT Authorization Grant, draft-ietf-oauth-identity-assertion-authz-grant) instead of a plain access token changes what the client receives. An ID-JAG is a short-lived, audience-restricted grant that asserts an identity was already verified, without itself being a token the target audience accepts for API access. It is useful when an agent needs to hand proof of its identity onward rather than call the target audience directly. Allow issuing ID-JAG must be turned on for a client before it can request one. An ID-JAG is redeemed for an access token in a second call to the token endpoint, authenticated as the same client it was issued to. Each ID-JAG can be redeemed exactly once: the gateway records its unique grant id for as long as the grant remains valid and rejects any second redemption attempt within that window, so a captured grant cannot be replayed after it has already been used. ## What keeps an exchange safe Every exchange is evaluated against the gateway’s own policy configuration, the same engine that governs proxied requests, before a token is minted. A redeemed ID-JAG can only ever narrow the scopes it was originally granted: a redemption request for a scope outside what the ID-JAG authorised has that scope dropped, never added, so an ID-JAG can never be traded for more access than it was issued for. The token endpoint also throttles repeated attempts per client id and per source address, locking out a key that exceeds its limit, so guessing at a Client Secret is rate-limited rather than left open. ## Relationship to Caller Context Binding [Caller context binding](/products/affinidi-trust-fabric/agent-gateway/concepts/caller-context-binding.md) scopes a surface’s delegated-credential vault to one caller at a time, using a composite key built from the agent’s DID, a hash of the caller’s identity, and the external provider. Token exchange is unrelated to that vault: an STS Client’s subject token can carry a caller’s own identity claims, an agent’s, or a chain of both, but the STS never reads or writes vault entries. The two mechanisms can describe the same caller without depending on each other. Credential Delegation authorises which stored token gets injected into an outbound call, while a token exchange separately re-scopes whichever identity assertion the client already holds for the next audience it needs to reach. ## Relationship to Workload Binding [Workload Binding](/products/affinidi-trust-fabric/agent-gateway/concepts/workload-binding.md) and token exchange both let one system vouch for an identity to another, but they work differently. Workload Binding runs automatically on an outbound edge, a Transit Point or a target leg, embedding the caller’s context into a signed Verifiable Presentation without the agent making an explicit request. Token exchange is an explicit call the client makes to the STS token endpoint, on demand, to obtain a token scoped to whichever audience it needs next. Both preserve a delegation trace: Workload Binding’s delegated flag records whether the sending gateway was acting for a caller, and token exchange’s act claim records the equivalent chain of actors inside the issued token itself. ## Relationship to trust registries [Trust registries](/products/affinidi-trust-fabric/agent-gateway/concepts/connections/trust-registry.md) verify an agent’s credentials against an external registry, feeding the result into OPA policy so a gateway can decide whether to trust an unfamiliar agent at all. Token exchange assumes that question is already settled: it works from an identity assertion the client already holds and re-scopes it, rather than establishing whether the identity should be trusted in the first place. Both mechanisms feed the same gateway policy engine that ultimately allows or denies a request. ## Use cases Calling a downstream audience the agent never authenticated to. An agent already holds a token proving who it is. Rather than requiring a fresh login for every new downstream service it needs to reach, its STS Client exchanges that token for a narrower one scoped to just the audience and scopes the new call needs. Handing off identity without granting the call itself. An agent needs another service to know who it is without that service gaining standing to make the call directly. Requesting an ID-JAG instead of an access token gives the agent an audience-scoped assertion of identity it can pass on, redeemable once for a real access token when the receiving side is ready to act on it. Preserving a chain of custody across a delegated action. An orchestrating agent exchanges a token on behalf of a subject caller, supplying its own actor token alongside the subject’s. The issued token’s act claim records that the orchestrator acted for the subject, so a downstream policy decision or audit entry can see both identities rather than only the outermost one. ## Related - [STS Clients](/products/affinidi-trust-fabric/agent-gateway/reference/authentication/sts-clients.md): field reference and dashboard steps for creating and configuring an STS Client. - [Agent identity and DIDs](/products/affinidi-trust-fabric/agent-gateway/concepts/identity.md): how the gateway derives the DID and claims a subject token typically carries. - [Caller context binding](/products/affinidi-trust-fabric/agent-gateway/concepts/caller-context-binding.md): how per-caller delegated credentials are scoped and isolated, independently of the STS. - [Workload Binding](/products/affinidi-trust-fabric/agent-gateway/concepts/workload-binding.md): the automatic VP-based alternative for attesting caller identity across a gateway-to-gateway edge. - [Trust registries](/products/affinidi-trust-fabric/agent-gateway/concepts/connections/trust-registry.md): how the gateway checks an agent’s credentials against an external registry.