tag is parsed. Two tags cover both CORS-tagged and non-CORS fetches. -->How ID-JAG helps AI agents authenticate | Nango Blog 11.1k<br>Log In Sign Up<br>Theme

Table of Contents

AI agents need access to third-party APIs to act on a user’s behalf. So far, that access is mostly approved by the users themselves, clicking “Allow” on an OAuth screen for every API. In an organization where many people use the same agent, each user has to authorize every API. This doesn’t scale.<br>Organizations already control which apps their employees can use, and they want the same control and visibility over the API integrations their agents rely on. ID-JAG gives them that by moving the decision from the user to the organization’s identity provider (IdP).<br>On June 18, 2026, MCP shipped enterprise-managed authorization, and the OAuth extension behind it, ID-JAG, went from something conceptual to running in Claude, VS Code, and popular SaaS apps.<br>What is ID-JAG?<br>ID-JAG stands for Identity Assertion JWT Authorization Grant. It lets your identity provider (IdP), like Okta, give an AI agent a scoped, short-lived token for another app’s API, like Salesforce, without sending every user through a consent screen or handing the agent a long-lived API key.<br>It does not invent a new protocol. It chains two that already exist: OAuth token exchange to get the ID-JAG from your IdP, and the JWT bearer grant to trade it for a real access token at the target app.<br>The ID-JAG itself is a signed token (a JWT) that says, in effect: this app can get a token for that API, on behalf of this user, with these scopes. Okta’s implementation of it is called Cross-App Access (XAA).<br>How it works<br>Without ID-JAG, every user connects every app themselves. A thousand employees using an AI assistant that reaches Salesforce means a thousand trips through Salesforce’s consent screen, one per person. Each grant is between that employee and Salesforce, so the company has no central control over which agents reach which apps, and nowhere to revoke it all at once.<br>ID-JAG moves that decision to the identity provider. The agent never asks the user to approve anything. It asks the IdP, which already knows what each employee is allowed to use:<br>The user signs in to the agent through their normal SSO, and the IdP issues an ID token.<br>The agent sends that ID token back to the IdP and asks for access to a specific app. The IdP checks the org’s policy: can this person, through this agent, reach Salesforce?<br>The IdP returns the ID-JAG, a signed token naming the agent, the user, and the app it is good for.<br>The agent presents the ID-JAG to Salesforce, which confirms the trusted IdP signed it and returns an access token.<br>The agent calls the API with that token.<br>The request in step 2 is a token exchange with the IdP:

POST /token<br>grant_type=urn:ietf:params:oauth:grant-type:token-exchange<br>requested_token_type=urn:ietf:params:oauth:token-type:id-jag<br>subject_token=<br>audience=https://salesforce.example.com # the app you want to reach

The agent then trades the ID-JAG at the app using the JWT bearer grant (grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer).<br>When the access token expires, it comes back to the IdP for a new one rather than holding a refresh token of its own. That is what lets a company control and revoke agent access from the IdP.<br>Why ID-JAG matters<br>The use case today is enterprise control: an admin sets one policy at the IdP for what agents can reach, and can revoke that access from one place.<br>That is why it is being adopted so quickly. The MCP launch shipped with Okta as the first IdP, Claude and VS Code as the clients, and Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase as the first apps behind it, with Slack on the way. ID-JAG is a standard OAuth grant, so any IdP and any app can adopt it.<br>Where ID-JAG falls short<br>ID-JAG is new, and it has the rough edges of anything new. Org-level control over agent access is a real step forward. But from building auth across 800+ APIs, we see a few limits that hold it back today:<br>Every app has to support it, and most don’t yet: your IdP supporting ID-JAG is not enough on its own. Each app or MCP server the agent reaches has to support it too. That list is very short today, but this could grow over time.<br>It only works over OAuth: ID-JAG is built on OAuth, so a provider that uses API keys, plain JWTs, or its own scheme cannot take part unless it switches to OAuth. That leaves out a lot. Plenty of APIs are key-only (Stripe platform operations, SendGrid, most analytics tools), and plenty that do use OAuth ship their own version of it (see why OAuth is still hard in 2026).<br>It controls who can act, not what they do: the token says the agent may reach Salesforce as this user but it does not control what the agent does with that access nor make your agent inherently secure against prompt injection attacks (see building reliable tool calls for AI agents).<br>Common questions about ID-JAG<br>Is ID-JAG replacing OAuth?<br>No. ID-JAG is an OAuth...