How ID-JAG Helps AI Agents Authenticate

AI agents are moving from chat boxes to doing real work. They query databases, send messages, update tickets, and reach across a dozen third-party apps to act on your behalf. That shift breaks the old authentication model.

Every tool an agent touches has traditionally meant another OAuth consent screen or another long-lived API key floating around your systems. ID-JAG fixes this. It lets your identity provider hand agents scoped, short-lived tokens for other apps' APIs, with no per-app consent screen required.

This article breaks down what ID-JAG is, how the authentication flow works step by step, where it fits alongside Cross-App Access, and the limits worth knowing before you adopt it.

What Is ID-JAG?

ID-JAG stands for Identity Assertion JWT Authorization Grant. It lets your identity provider (IdP), miniOrange, for example, give an AI agent a scoped, short-lived token for another app's API, such as Salesforce. It does this without routing every user through a consent screen or handing the agent a long-lived key.

Crucially, ID-JAG doesn't invent a new protocol. It chains two OAuth standards that already exist. It uses OAuth token exchange to get the ID-JAG from your IdP, then the JWT bearer grant to trade it for a real access token at the target app. The ID-JAG itself is a signed JWT that asserts, in effect: this agent may get a token for that API, on behalf of this user, with these scopes.

For AI agent authentication, that's a meaningful change. Authorization shifts from a per-user, per-app decision to a single, centrally governed policy. ID-JAG extends the trust model of single sign-on into the realm of API access. The same IdP your apps already trust for SSO now brokers API access between them. First published as an IETF draft in 2024, it moved into production in mid-2026 when MCP shipped enterprise-managed authorization built on top of it.

Why AI Agents Need a New Authentication Model

The old model doesn't scale for agents. Consider a single AI assistant used across an organization. A thousand employees using an assistant that reaches Salesforce means a thousand trips through Salesforce's consent screen, one per person. Worse, each grant is a private relationship between that employee and Salesforce, so the company has no central place to see it or shut it off.

This creates three concrete problems:

• Consent fatigue: In the context of AI agents, more tools typically mean more consent pop-ups. Users start clicking "Allow" reflexively, which is the opposite of informed authorization.
• Shadow AI: Employees connect unapproved AI tools to company data with no oversight. This shadow AI problem, where internal users connect unapproved tools to handle company data, creates a high risk for data leaks.
• No central revocation: Because grants live between individual users and individual apps, there's nowhere to revoke access all at once.

Organizations already control which apps employees can use. They want the same control and visibility over the API integrations their agents rely on, and moving the decision to the IdP is how they get it.

How ID-JAG Works: The Authentication Flow

The ID-JAG architecture rests on a simple reframing. The agent never asks the user to approve anything. It asks the IdP, which already knows what each employee is allowed to use. Four roles participate: the requesting agent, the enterprise IdP, the target app's authorization server, and the resource server (the actual API). The flow runs in five steps.

User Signs In via SSO

The user signs in to the agent through their normal SSO, and the IdP issues an ID token. This is standard OpenID Connect, the same SSO login your apps already run. The ID token is the seed of trust that everything downstream builds on. Nothing new is asked of the user at this point.

Identity Is Delegated to the AI Agent

The web app passes that ID token to the agent so it can act on the user's behalf. This is where identity delegation happens. The user's verified identity, established once at sign-in, is now available for the agent to present downstream. Importantly, the agent isn't impersonating the user. The token it eventually receives will name both the human and the agent acting for them.

Token Exchange Between Services

The agent sends the ID token back to the IdP and requests access to a specific app. This is an OAuth token exchange, and the IdP evaluates the organization's policy before responding: can this person, through this agent, reach Salesforce? If approved, the IdP returns the ID-JAG. The request looks like this:

POST /token
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
requested_token_type=urn:ietf:params:oauth:token-type:id-jag
subject_token=<the user's ID token>
audience=https://salesforce.example.com
scope=chat.read chat.history

The agent then trades the ID-JAG at the target app using the JWT bearer grant (grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer). A key detail from the draft: the IdP must not issue access tokens in response to an ID-JAG it issued itself, since doing so could broaden the scope of authorization unintentionally. The two authorization servers stay separate on purpose.

AI Agent Accesses Protected Resources

The target app's authorization server confirms a trusted IdP signed the ID-JAG, then returns a real access token. This is a standard OAuth Bearer token, typically valid for around an hour. The agent uses it to call the API and do the work it was asked to do.

Here's the detail that gives organizations their control. When the access token expires, the agent comes back to the IdP for a new one rather than holding a refresh token of its own. That single design choice is what lets a company govern and revoke agent access from one place. The IdP re-runs its policy check on every renewal, so revoking access is as simple as changing a policy. There's no hunting down scattered credentials across a dozen apps.

The ID-JAG carries rich context in its claims: the sub (the human user), the client_id (the agent), the aud (the target authorization server), the scp (granted scopes), and the issuing IdP. This lets the token record on whose behalf, which agent, and to what extent a resource was accessed. And because the IdP runs a centralized policy evaluation on the token exchange, it separates the scopes requested by the AI or external app from the scopes the organization actually permits. That's a safety net that overwrites over-broad requests with what your security standards allow.

ID-JAG and Cross-App Access (XAA)

You'll often see ID-JAG mentioned alongside Cross-App Access, and it's worth being precise about the relationship. XAA is Okta's implementation and branding of the ID-JAG standard. In Okta's model, an authorization-server resource connection is supported by Cross-App Access, which uses ID-JAG.

Put simply, ID-JAG is the open standard, meaning the grant type and the signed token. XAA is one vendor's product built on it. Because ID-JAG is a standard OAuth grant, any IdP and any app can adopt it, and other identity providers are free to implement the same specification under their own names. LY Corporation's open-source Athenz platform, for instance, has begun supporting ID-JAG independently of Okta.

ID-JAG vs Traditional OAuth

A common misconception is that ID-JAG replaces OAuth. It doesn't. ID-JAG vs OAuth is the wrong framing, because ID-JAG is an OAuth extension, not a competitor. It reuses token exchange (RFC 8693) and the JWT bearer grant (RFC 7523), and it sits on top of the OAuth your apps already run for SSO.

Everything OAuth already does stays in place. ID-JAG simply relocates the authorization decision from thousands of individual users to a single administrative policy, which is exactly what makes it work for agents operating at scale.

Benefits of ID-JAG for AI Agents

Beyond the smoother user experience, ID-JAG delivers concrete wins for AI agent security and operations.

A clear audit trail

Because every issuance routes through the IdP, connection facts aggregate in one place. The IdP can issue tokens containing the necessary context about both the human user and the AI agent, maintaining a clear audit trail across systems. That's invaluable when assigning responsibility after an incident or proving compliance.

Centralized control over shadow AI

The IdP is positioned to intercept and evaluate unapproved tools, bringing previously opaque external AI connections under standard, manageable processes.

Less token sprawl

Perhaps the biggest operational win. The specification recommends that resource servers not issue separate refresh tokens. Instead, clients re-submit an ID-JAG to refresh their access token. This replaces long-lived credentials scattered across systems with protocol-based, dynamic trust. No more API keys and refresh tokens piling up in a dozen places.

Adoption reflects the appeal. The MCP launch shipped with Okta as the first IdP, Claude and VS Code as clients, and apps including Asana, Atlassian, Canva, Figma, Linear, and Supabase behind it.

Limitations and Operational Considerations

ID-JAG is new, and honesty about its rough edges matters. The ID-JAG limitations worth weighing before adoption fall into a few buckets.

It's still a draft

ID-JAG remains an IETF Internet-Draft, not a finalized RFC. Its mechanics may shift, so tightly coupling core architecture to today's spec carries some risk.

Every app has to support it, and most don't yet

Your IdP supporting ID-JAG isn't enough. Each target app or MCP server must support it too. That list is short today.

It only works over OAuth

Providers that use API keys, plain JWTs, or their own scheme can't take part unless they switch to OAuth. That leaves out key-only APIs like Stripe platform operations and most analytics tools.

It controls who can act, not what they do

The token says the agent may reach an app as this user, but it doesn't govern what the agent does with that access or protect against prompt injection.

There are operational nuances too. Because an ID-JAG is a JWT, it's difficult to instantly invalidate once issued and propagated. Short validity periods with frequent renewals are the practical path to effective revocation.

The IdP may also demand step-up authentication at exchange time, returning an insufficient_user_authentication error when the subject's authentication context doesn't meet policy. Your system needs logic to handle re-authentication prompts. Finally, ID-JAG is recommended for confidential clients. Public clients like standalone mobile apps should stick with the interactive authorization code grant.

Conclusion

ID-JAG is a genuine step forward for AI agent authentication. By moving the authorization decision from thousands of individual consent screens to a single IdP policy, it tackles consent fatigue, shadow AI, and token sprawl in one architectural move.

At the same time, it gives organizations the audit trail and central revocation they need. It's not magic. It's still an IETF draft; it only works over OAuth, and app support is early. But for the apps already living inside your identity provider, ID-JAG turns agent access from an ungovernable sprawl into something you can see, control, and shut off from one place. That's exactly the foundation the agent era needs.

FAQs

Is ID-JAG replacing OAuth?

No. ID-JAG is an OAuth extension, not a replacement. It reuses token exchange and the JWT bearer grant and sits on top of the OAuth your apps already run. What it removes is the per-app consent screen for apps sharing an IdP.

What's the difference between ID-JAG and XAA?

ID-JAG is the open standard, meaning the grant type and signed token. Cross-App Access (XAA) is Okta's implementation and branding of it. Other identity providers can implement ID-JAG and call it something else entirely.

Is ID-JAG only for MCP?

No. ID-JAG is a general OAuth grant. MCP's enterprise-managed authorization is the first high-profile system built on it, but any OAuth client and app can implement the same flow.

Does ID-JAG make my AI agent secure?

Not by itself. ID-JAG controls who can act and which app they can reach. It doesn't govern what the agent does with that access or defend against prompt injection. It's one layer in a broader security posture.

How is ID-JAG different from workload identity federation?

They secure different parts of an agent's path and stack rather than compete. ID-JAG handles a human delegating to an agent that calls another app's API. Workload identity federation handles a workload getting short-lived credentials instead of a static key.