Why Token Exchange Is the Most Underrated Grant Type in OAuth

Ok. I want to talk about something.

For years, token exchange (RFC 8693) has been the most underrated grant type in OAuth. It’s been the quiet worker bee, moving tokens across trust boundaries while everyone obsessed over authorization code flow and PKCE. Here’s the fun thing though: it’s not being underrated anymore. It’s recently bee drafted up to the majors and into being the foundation of how AI agents are going to authenticate to everything, and the standard for doing that is moving quick.

I’m going to be talking about ID-JAG here, so if you’re not tracking it yet, you’re about to be.

Here’s a Quick Refresher and a Level-Set

So, foundationally, traditional token exchange lets you trade one token for another. Cool. Big whoop. You can get a token with a different audience, different scope, or different type, but inside a trust relationship that already exists. You’re not doing a fresh login or session refresh. You’re, very simply, taking a credential that you already have and getting back something purpose-built for the next hop.

There are two ways to do this and I don’t think this horse is dead enough so here we go:

  1. Impersonation
    • The new token looks like the original subject got it directly. This might be clean, but the chain of custody completely disappears
  2. Delegation
    • An actor_token in the request and an act claim in the retunred access token preserve who’s really acting on whose behalf
    • This is handy every time you might need to answer “who actually did this” during things like an incident review.

That was true before agents showed up, and holy crap if it’s not true now.

Why Agents Broke the Old Model

So here’s the problem with agents.. Right now, most AI agents run on your actual credentials. A lot of these tools just hold the user’s own token and just… act with it (heh). That security model is a disaster waiting to happen. With only one compromised agent session, you’ve given an attacker the same blast radius as the human it was impersonating (there’s that word again…).

One thing to be concerned about is that consent fatigue and shadow AI aren’t hypothetical problems anymore. The more services an agent touches, the more token sprawl your security team has to track (or should be tracking) without having visibility into any of it.

Token exchange is exactly the mechanism built to fix this. It just needed a profile specifically shaped for the agentic use case. Enter ID-JAG.

ID-JAG, In Plain Terms

ID-JAG (Identity Assertion JWT Authorization Grant) takes an identity assertion you already have from SSO (typically an OIDC ID token or a SAML assertion) and uses token exchange to turn it into a scoped, audience-specific grant for a completely different application without needing to re-authenticate. Like traditional federation, it uses existing SSO trust relationships to get cross-domain access tokens without requiring the user to interact.

That’s the trick that makes it valuable for agents. Specifically that there’s no OAuth redirect hell for every tool an agent needs to call on your behalf. The trust relationship you already have with your IdP does the work for you.

Ok, So What Does the ID-JAG Flow Actually Look Like

Say you’re using a chat app (call it Chattie) and it needs to pull data from a Wiki app on your behalf. Both apps must first trust the same corporate IdP for SSO (this is non-negotiable. If they don’t share an IdP, ID-JAG doesn’t apply). Here’s what happens:

Step 1: You log into Chattie. This is a standard OIDC flow. Chattie redirects you to the IdP, you authenticate, and Chattie gets back an ID token. Audience (aud) is Chattie’s client ID. Nothing weird yet.

Step 2: Chattie wants to call Wiki’s API to complete the request. Instead of throwing a consent screen in your face, Chattie quietly takes your ID token that it already has and does a token exchange at the IdP’s token endpoint. The request looks roughly like this:

POST /token
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
requested_token_type=urn:ietf:params:oauth:token-type:id-jag
subject_token=<the ID token>
subject_token_type=urn:ietf:params:oauth:token-type:id_token
audience=wiki.example.com

The IdP checks its policy, (has an admin actually approved Chattie talking to Wiki for this user, this org, this scope?) and if so, mints an ID-JAG. Please note: the ID-JAG is not an access token, it’s just an assertion. An assertion is just a signed note from the IdP that says “Chattie is allowed to act on this user’s behalf toward Wiki.” It doesn’t grant access on its own.

Step 3: Chattie presents the ID-JAG to Wiki’s authorization server This is not Wiki’s API, it’s its AS. This also uses the JWT-bearer grant (RFC 7523, the older, boring cousin in this family of specs):

POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<the ID-JAG>

Wiki’s AS then validates the ID-JAG (signature, issuer, audience, etc), applies its own local policy because trusting the IdP’s say-so doesn’t mean Wiki has to grant everything requested, it’s an intdependent AS after all… Only then does it issues a real, local, scoped access token back to the agent.

Step 4: Chattie calls Wiki’s actual API with that access token. Normal API call bearer token stuff from here on out.

Notice what never happened anywhere in this flow. There’s no redirect to a consent screen, no OAuth app registration between Chattie and Wiki, no static API key sitting in Chattie’s config just begging to be leaked. Two token exchanges, two policy checks, and one IdP doing the introduction, that’s all it is.

Here’s Why I Think it’s Going to Become The Standard

I don’t typically say that things are becoming the standard lightly. Here’s my research on this:

It’s racing through IETF. The draft was first published individually in March 2024, then in June 2025 it got announced as a next-generation standard candidate officially backed by Okta. That’s the jump from “a proposal” to “a major identity company is staking its identity roadmap on this.” As of this writing it’s on its fourth revision and on the standards track with some real momentum behind it.

It’s not just an Okta thing anymore. Aaron Parecki (co-author of ID-JAG) is leading the broader Cross App Access initiative for ID-JAG and Identity Chaining implementation across the industry, not just inside one vendor. And to be fair, Identity Chaining (Which seems to combine token exchange with JWT bearer assertions, of which ID-JAG is the SSO-specialized profile) is on a separate standards-track draft in its own right. So if you’re reading this, good on you Aaron!

Other implementations are already shipping. Keycloak (an open-source IdP) recently added preview support for JWT Authorization Grant in version 26.5. That’s a tell you can look for with any spec: when open-source implementations start shipping support before the RFC number even officially exists, you’re looking at something that’s not going anywhere.

Anthropic is already living this exact pattern. Anthropic also shipped workload identity federation this year that lets a Kubernetes service account JWT mint a short-lived API token on demand instead of a long-lived static key sitting in an environment variable somewhere just waiting to be leaked. This isn’t ID-JAG per say, but it has the same underlying philosophy: stop handing out durable, broad credentials and start exchanging short-lived, purpose-scoped ones at the moment they’re needed. That’s the idea behind the whole ID-JAG thesis. I think this is just us watching independent teams arrive at it in parallel.

The Edge Case Nobody’s Solved Yet: The Internal Hop Problem

So let’s day that ID-JAG solves crossing the trust domain boundary. Your company’s IdP is handing an agent a token that a partner SaaS app will trust. Great. But once that agent is inside your walls, calling five internal microservices in sequence to complete one task, you’ve got a second problem ID-JAG alone doesn’t fully address: how do you keep the “who’s really acting, and for what specific purpose” context intact across an internal chain of calls, without just forwarding the same broad token hop after hop after hop?

There’s a few things in draft that can solve this probelm, but I think it’s just a bit early to make a prediction on who might win out.

TL;DR

  • Token exchange (RFC 8693) was always the right tool for agent delegation. ID-JAG is the profile that makes it purpose-built for AI agents specifically, using existing SSO trust to skip redirect-based re-auth entirely.
  • This isn’t vaporware momentum. It went from an individual draft to an Okta-backed standards candidate in about a year, it’s on its fourth spec revision, and Keycloak already shipped preview support.
  • ID-JAG handles crossing trust domains and is the best way you can show a delegated agent acting on behalf of a user across trust domains.
  • If your agents are still just holding raw user tokens and calling it a security model, the standard for fixing that already exists. The only question is whether you adopt it before or after your first bad incident review.