ID-JAG [What It Changes]

TL;DR

• ID-JAG (Identity Assertion JWT Authorization Grant) is the IETF OAuth grant that lets an identity provider issue a short-lived, scoped assertion so an agent can obtain an access token at another app's API without sending every user through that app's consent screen.

• As of 18 June 2026, MCP's Enterprise-Managed Authorization extension went stable and used ID-JAG under the hood, with Okta as the first IdP and Claude, VS Code, Asana, Atlassian, Figma, Linear, and Supabase named at launch.

• Nango independently explains the two-step chain as RFC 8693 token exchange plus RFC 7523 JWT bearer. Keycard confirmed ID-JAG support on the June wave as early access.

• This is a protocol, not a SKU. Okta's Agent SSO is one implementation. A 2-truck shop, a 10-person agency, or a solo clinic should care when an assistant needs Asana or the EHR API and today that means one OAuth dance per person.

Industry figures, not list prices.

Industry figures, not list prices.

Industry figures, not list prices.

According to AICPA, 62% of firms reported cloud-workflow adoption.

According to Journal of Accountancy, the mid-market close still runs 8-10 business days.

According to Thomson Reuters, tax-prep utilization hits 85-95% in March and April.

According to NFIB, 44% of small businesses cite time-management. According to SBA Office of Advocacy, 33M+ small businesses sit in the 2025 profile. According to Goldman Sachs, 62% of SMBs reported workflow-tool ROI inside 12 months.

Key Takeaways

• ID-JAG is the grant. Cross App Access (XAA) is Okta's name for its implementation. MCP Enterprise-Managed Authorization is the first high-profile profile of the grant.

• The IETF draft is draft-ietf-oauth-identity-assertion-authz-grant-04, 21 May 2026, expires 22 November 2026. It is not a ratified RFC.

• Nango names the scaling failure: a thousand employees using an assistant that reaches Salesforce means a thousand consent screens.

• Most APIs still do not speak ID-JAG. Nango's own limits: every app must support it, it only works over OAuth, and it controls who can act, not what they do.

• Teams already routing delegated SaaS calls through US Tech Automations agent steps will plug ID-JAG in as a token exchange, not a new CRM, alongside the capture path in best form-to-CRM automation tools.

What ID-JAG is, in one sentence

ID-JAG is a signed JWT authorization grant, issued by the organization's identity provider, that says this agent may obtain a token for that API on behalf of this user with these scopes, then gets redeemed at the API's own authorization server. That is the entity. It is not Okta, not MCP, and not a product you license by the seat.

A 2-truck HVAC shop feels this when the dispatch assistant needs to read the calendar and write the job in the field-service app: today each technician clicks Allow, or worse, shares one integration user. A 10-person agency feels it when Claude needs Figma and Asana for every designer. A solo clinic feels it when a scribe agent needs the practice-management API and there is no admin console, only a personal OAuth grant that dies when the doctor resets a password. ID-JAG moves the Allow from the person to the IdP policy. If your apps are not on the short list, nothing changes this week.

What moved in June 2026

On 18 June 2026 the MCP blog declared Enterprise-Managed Authorization stable. Admins enable an MCP server once; users inherit it scoped to groups and roles; nobody sees a per-server consent screen. Under the hood the client obtains an ID-JAG from the IdP during SSO and exchanges it at the MCP server's authorization server.

Early adopters listed there: Okta as first IdP; Anthropic in Claude, Claude Code, and Cowork; Visual Studio Code; resource servers Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase, with Slack adding support.

Okta's 23 June 2026 partners post expanded the roster to 25-plus names, including Cursor, Docker, VS Code, Cloudflare, Keycard, Keycloak, Slack, Zoom, and others, with Workforce access from August 2026.

Keycard's announcement treats ID-JAG as joining OAuth, A2A, and MCP in the standards it speaks, with support in early access.

The draft itself profiles OAuth Identity Chaining (I-D.ietf-oauth-identity-chaining) by requiring an identity assertion (OIDC ID token or SAML) as the token-exchange subject_token.

Sources: Nango; MCP EMA; IETF ID-JAG; Okta XAA.

How the two-step chain works

Nango's walkthrough:

1. The user signs in to the agent through normal SSO. The IdP issues an ID token.

2. The agent sends that ID token back to the IdP and asks for access to a specific app. The IdP checks org policy.

3. The IdP returns the ID-JAG, a signed JWT naming the agent, the user, and the app it is good for.

4. The agent presents the ID-JAG to the target app (Salesforce in Nango's example), which verifies the trusted IdP signed it and returns an access token.

5. The agent calls the API with that token. When it expires, the agent returns to the IdP rather than holding a refresh token of its own.

The token-exchange request uses grant_type=urn:ietf:params:oauth:grant-type:token-exchange and requested_token_type=urn:ietf:params:oauth:token-type:id-jag. The second hop uses grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer.

The draft requires JWT typ of oauth-id-jag+jwt. Required claims include iss, sub, aud (the resource authorization server), client_id, jti, exp, and iat. Optional claims include scope, resource, authorization_details (RAR / RFC 9396), tenant, and email.

The resource authorization server still decides whether to honor the grant and what access token to issue. The IdP does not mint the downstream API token. That split is the point: centralized identity, local API policy.

The draft's enterprise example is a wiki embedding chat from another vendor, both already trusting the same IdP for SSO. That is closer to a 10-person agency than to a greenfield protocol lab: you already have Okta (or another IdP) for login, and you want the assistant to read the wiki and write the chat thread without a second OAuth circus. Subject resolution can use iss+sub, optional email, or aud_sub. JIT provisioning is allowed when policy says so. SAML shops are not excluded: the draft defines a sub_id format saml-nameid so the resource authorization server can resolve the same human it already knows from SSO.

Refresh tokens at the resource authorization server are discouraged in the parent chaining spec. When the access token dies, the client goes back to the IdP for a new ID-JAG. That is how a departed employee loses agent API access when their IdP session ends, instead of leaving a long-lived Salesforce refresh token in the agent's vault.

Okta's AI Agents at Work survey is the operational backdrop, not the protocol: only 34% of organizations apply the same controls to agents as to humans. ID-JAG is how an IdP applies those controls to the hop across apps. It does not create the policy for you.

MCP's specification page repeats the same flow for clients, servers, and authorization servers, including account linking via sub and optional email.

Why now: the constraint that broke

Per-user OAuth was designed for a person connecting one app. Agents multiply the cartesian product: users × tools × APIs. According to Nango, 900-plus APIs sit in its catalog, and most of them cannot join ID-JAG until they speak OAuth.

According to Okta's 23 June release, the alternative was high-risk static API keys and consent screens invisible to the IT admin, creating standing privilege.

Beri is blunt: a product that brokers agent access without ID-JAG is brokering API keys.

Limits Nango names, and they are load-bearing

Every app has to support it. IdP support is not enough. The list of resource apps is short.

It only works over OAuth. Stripe platform keys, SendGrid, most analytics tools, and custom JWT schemes are out unless they switch.

It controls who can act, not what they do. A token that says "this agent may reach Salesforce as this user" does not stop a destructive action inside that scope. Runtime policy (OPA, Cedar, a gateway) is a different layer. The MCP EMA write-up is honest that the IdP's visibility ends at token issuance.

Okta Developer still walks through a local sample with Agent0 and Todo0; the August 2026 changelog on that post says Admin Console catalog apps were replaced by Directory > AI Agents — implementation details move even while the grant stays.

USTA analysis: consent-screen fan-out versus one IdP policy

USTA analysis. Inputs from Nango's scaling example and the MCP launch roster. Nango states that 1,000 employees using an assistant that reaches Salesforce means 1,000 consent screens in the classic model. MCP EMA plus ID-JAG collapses that to 1 admin enablement per server, inherited by those 1,000 users See group policy.

Consent events avoided on one API: 1,000 − 1 = 999. On the 7 resource apps named at the MCP launch (Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase), a naive cartesian product is 1,000 × 7 = 7,000 user consents versus 7 admin enables, a reduction of 6,993 consent events (99.9% of that cartesian product).

That math is a count of consent prompts, not a security proof. It assumes every user needed every server and that the IdP policy is correct. It also assumes those seven apps are the ones you use. A clinic whose EHR is key-only still has 1,000 of nothing: ID-JAG cannot attach. The analysis only shows why enterprises adopted the grant quickly on the MCP roster, and why Nango's "most don't yet" caveat is the SMB-relevant remainder.

Who this is for in an SMB shop

If you already use Okta and Claude or VS Code against Asana, Figma, Linear, or Atlassian, ID-JAG is how those connections should look after an admin enablement, not after a staff-wide OAuth drill.

If you are on Microsoft-only agents calling Graph, this grant is not what Entra is issuing you today; that is a different object model described in Entra Agent ID.

If your stack is Jobber plus a spreadsheet, wait. Ask vendors whether they redeem ID-JAG. Until they do, a shared integration user is still the honest description.

A concrete week-one script for an agency already on Okta and Claude: enable the Figma and Asana MCP servers in the IdP, confirm a designer can invoke them without a consent prompt, then revoke the designer in Okta and confirm the next call fails. If revoke does not kill the downstream token on the first expiry window, you do not yet have the grant — you have a marketing name on top of a refresh token. Nango's "comes back to the IdP for a new one" sentence is the test.

Legal and transactional practices on Clio alternatives and Smokeball versus Clio will meet this only when those vendors' APIs redeem the assertion. Until then, treat practice-management API keys as keys.

Solo-lawyer workflow tools hit the same consent-fan-out when an assistant needs the practice system and email. ID-JAG helps only if both ends implement it.

Shops already calling third-party APIs from US Tech Automations workflows should store "how this connector authenticates" as XAA, user OAuth, or static key — then retire keys where ID-JAG exists.

A third mention: when US Tech Automations routes an agent from intake to a SaaS write, the grant belongs on that hop, not on the homepage form.

Signal vs Speculation

Demonstrated fact (sourced). ID-JAG exists as draft-04. MCP EMA is stable as of 18 June 2026 with a named adopter list. Okta branded it Cross App Access and listed 25-plus partners on 23 June. Keycard and Nango independently documented the flow. RFC 8693 and RFC 7523 are the building blocks. The draft is not an RFC. Most APIs are not in the roster.

Our read: over 12–36 months, SMB teams will meet ID-JAG as a checkbox in Claude or VS Code, not as an IETF reading group. The grant will cover the collaboration suite first (Atlassian, Figma, Linear, Slack) and lag on vertical SaaS (HVAC, clinic, legal). If draft-04 stalls, vendors will keep shipping "XAA" as a product name on top of keys. If it becomes a Proposed Standard, more resource servers can implement without waiting for Okta. Do not plan a single grant to cover Stripe keys or SendGrid; Nango already closed that door.

FAQ

What is ID-JAG?

ID-JAG is the Identity Assertion JWT Authorization Grant, an IETF OAuth Internet-Draft that lets an IdP issue a short-lived assertion an agent redeems at another app's token endpoint, using RFC 8693 and RFC 7523.

Is ID-JAG replacing OAuth?

No. Nango states it is an OAuth extension that removes the per-app consent screen for apps that share an IdP.

What is the difference between ID-JAG and XAA?

ID-JAG is the standard grant. Cross App Access is Okta's implementation and branding. Other IdPs can implement ID-JAG under another name.

Is ID-JAG only for MCP?

No. MCP's enterprise-managed authorization is the first high-profile profile. Any OAuth client and resource authorization server can implement the same flow.

Does ID-JAG stop a bad tool call?

No. It answers whether the agent may connect with which scopes. Per-call allow/deny needs a policy enforcement point on the data path.

What to do this week

Ask your IdP, in writing, whether it issues ID-JAG assertions today and to which resource servers. Date the answer. For each agent, write down whether the downstream API is on the MCP/Okta roster. If it is not, keep treating the credential as a key with an owner.

Homepage: ustechautomations.com. When you are ready to put the hop in a workflow, open the agentic workflow builder and label the grant on the connector, not in a spreadsheet beside it.