XAA vs. ID-JAG vs. EMA: Untangling the Naming

Picture Northlight Analytics, a 200-person B2B company that just rolled out AI agents across its sales and support teams. Every rep now has an assistant that can pull data from Salesforce, Notion, and a couple of internal MCP servers. It works great — for the first ten people.

By employee thirty, Priya, who runs IT, is drowning. Every new hire needs to individually click through a consent screen for every single MCP server, one at a time. Someone connects a personal Gmail to a work tool by accident. When a contractor's engagement ends, Priya has to remember and manually revoke access across four different servers, because there's no single place that shows her everything that contractor could reach.

This is the exact mess that a trio of overlapping terms — XAA, ID-JAG, and EMA — exists to solve. Here's how they show up in Northlight's actual rollout, and how they relate to each other.

Priya's fix starts in the Okta admin console: XAA

Northlight already uses Okta for company logins. Priya finds a feature called Cross App Access (XAA) — Okta's product for exactly this problem. Instead of every employee individually authorizing every app, Priya configures policy once, in one console: "anyone in Sales can reach the CRM-agent MCP server. Anyone in Support can reach the ticketing one. Nobody else can reach either."

(Small industry note, since it'll come up if Priya starts researching this: Scalekit is one of the platforms Okta lists as adopting XAA directly, alongside names like Cloudflare and WorkOS — so if Northlight's internal MCP servers run on Scalekit's auth layer, a good chunk of this wiring is already handled.)

From Priya's seat, XAA is the product name. It's the thing she clicks around in, the thing her team will reference in tickets ("did you check the XAA settings for that server?"). She doesn't need to know exactly how it works under the hood to use it — but her engineering team does.

Under the hood, it's all running on ID-JAG

Northlight's engineer, Sam, is the one who actually has to make Northlight's internal MCP servers understand what Okta is sending them. When he reads the technical docs, "XAA" mostly disappears, replaced by a more precise term: ID-JAG, short for Identity Assertion JWT Authorization Grant.

Here's what Sam sees happen, step by step, every time an employee's agent connects to one of Northlight's servers:

1. The employee is already logged into Okta — that part happened at the start of their day, nothing new.
2. The client (their agent tool) asks Okta for an ID-JAG — a short-lived, signed token scoped to exactly one destination, like "the Support ticketing MCP server, and nothing else."
3. Okta checks its policy (the one Priya configured) before handing that token over.
4. The client presents the ID-JAG to Northlight's own MCP server, which validates it and mints its own access token.

Sam's takeaway, once he's implemented it: ID-JAG is the actual grant type doing the work — a fairly ordinary combination of two existing OAuth mechanisms (RFC 8693 token exchange and RFC 7523 JWT bearer grants), applied to a new problem. It's not MCP-specific on its own; it comes from a general IETF draft that Okta and other contributors have been shaping. What makes it Northlight's is how it's wired into their servers.

EMA is what ties it to MCP specifically

So where does "EMA" fit? Enterprise-Managed Authorization is the name the Model Context Protocol project gave to its own formal spec for this pattern — the extension that defines, at the protocol level, how an MCP client and MCP server negotiate and use this exact flow. It's the connective layer that makes sure Northlight's homegrown servers, Okta's XAA product, and whatever MCP client each employee happens to use can all agree on the same handshake, instead of every vendor inventing its own version.

When Sam implements support for this on Northlight's server, "EMA" is the capability he's advertising and negotiating. When Priya configures policy, she's clicking through Okta's XAA screens. When either of them reads a deep technical explanation of what's actually happening on the wire, they're reading about ID-JAG. Same underlying mechanism, three names, three different vantage points on it.

The one-line version

If you only remember one thing: EMA is the MCP-level agreement, ID-JAG is the token that agreement runs on, and XAA is one vendor's product built on top of both. For the fuller mechanics — including where this model's authority actually stops — see What Is Enterprise-Managed Authorization for MCP? →

And for what Priya's setup still doesn't cover once an agent is inside a server and actually taking actions, that's the subject of our next piece: The Action Gap: What EMA Secures, and What's Still Yours to Build →

Also in this series: Enterprise MCP: How Identity, SSO, and Scoped Auth Actually Work →, SSO-backed MCP Authentication →, When an Employee Leaves, Who Revokes Their AI Agent's Access? →.