MCP Enterprise-Managed Authorization, Explained (2026)

TL;DR

MCP Enterprise-Managed Authorization (EMA) is a stable MCP extension that lets an org’s identity provider decide which MCP servers an employee can reach, replacing per-server consent screens with a token relay called ID-JAG.

• The mechanism: SSO login → IdP issues an ID-JAG (RFC 8693 token exchange) → client trades the ID-JAG for a real MCP access token (RFC 7523 JWT-bearer) → no redirect to the MCP server’s own consent screen.
• Stable since: June 18, 2026, per the official MCP blog announcement.
• Shipping now: Okta (identity provider); Claude, Claude Code, Cowork, and VS Code (clients); Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase (servers), with Slack adding support.
• What it isn’t: a replacement for OAuth 2.1, or a runtime policy engine for what an agent does once it’s connected — more on that gap below.

Why EMA exists

Before EMA, an MCP rollout scaled headcount into a matching number of manual approvals. Every employee who wanted Claude talking to Linear, or Cursor talking to Figma, clicked through their own OAuth consent screen for their own account. Multiply that by a dozen MCP servers and a few hundred employees and IT has no single place to see, let alone control, what’s actually connected.

The MCP docs name the friction directly: employees shouldn’t need to understand the authorization details of every server their org uses; security teams can’t enforce consistent policy if each person authorizes independently; onboarding means manually re-authorizing dozens of services per new hire; offboarding means revoking access service-by-service instead of once. EMA answers all four by making the identity provider — the system that already governs email and Slack access — the authority for MCP too. The announcement puts the resulting experience in one line: “Authorize once, inherit everywhere: admins enable a server for the org. Users get it automatically, scoped to the groups and roles they already have.”

What EMA is: the pieces

EMA is registered as the MCP extension io.modelcontextprotocol/enterprise-managed-authorization. Extensions in MCP are opt-in and never active by default — both the client and the server have to declare support before the flow below ever triggers. Five actors show up in the spec’s own sequence diagram:

• Browser — handles the interactive SSO login step, same as any OAuth flow.
• MCP Client — Claude, Claude Code, Cowork, or VS Code: the app the user is actually working in.
• Enterprise IdP — Okta today. Authenticates the user and evaluates whether org policy allows this client to reach this server.
• MCP Authorization Server (MAS) — validates the token the IdP issued and mints the real MCP access token. May be the MCP server’s own auth stack or a separate service.
• MCP Resource Server (MRS) — the MCP server itself, the thing that actually executes tools/call.

How it works: the flow

┌──────────────────────────────────────────────────────────────┐
│         MCP Enterprise-Managed Authorization — 3 hops          │
├──────────────────────────────────────────────────────────────┤
│ 1. SSO login        Client --login--> IdP                      │
│                      Client <--ID Token-- IdP                  │
│                                                                  │
│ 2. ID-JAG exchange   Client --token-exchange (RFC 8693)--> IdP  │
│                      Client <--ID-JAG (~5 min TTL)-------- IdP  │
│                                                                  │
│ 3. Access token      Client --jwt-bearer (RFC 7523)--> MCP AS   │
│                      Client <--MCP access token------- MCP AS   │
│                                                                  │
│ Then: Client --tools/call, Authorization: Bearer--> MCP Server  │
│       No redirect to the MCP server's own consent screen.       │
└──────────────────────────────────────────────────────────────┘

Spelled out in the order the spec’s sequence diagram defines it:

1. Redirect to IdP. The client sends the user’s browser to the enterprise IdP to log in — standard SSO, nothing MCP-specific yet.
2. IdP issues an ID Token. After login, the client exchanges the IdP’s authorization code for an OpenID Connect ID Token (or a SAML assertion) and stores it.
3. Client requests an ID-JAG. The client exchanges that ID Token for an Identity Assertion JWT Authorization Grant. The IdP evaluates policy here — group membership, role, conditional-access rules — before issuing anything.
4. Client trades the ID-JAG for an access token. The client presents the ID-JAG to the MCP server’s Authorization Server, which validates it and returns a normal MCP access token.
5. Client calls the server. Every tools/call after that carries the access token in the Authorization header, exactly like any OAuth-protected MCP server.

The step users actually feel is what’s missing: there is no browser redirect to the MCP server’s own authorization endpoint, and no per-server consent screen. The spec is explicit that clients implementing EMA must not send the user through that redirect at all — the ID-JAG stands in for it.

The exact token requests

Two OAuth grant types do the work, and both are existing IETF standards — EMA doesn’t invent a new token type, it composes two. Step one is a Token Exchange request (RFC 8693) against the IdP, asking specifically for an ID-JAG:

POST /token HTTP/1.1
Host: idp.example.com
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
&audience=https://auth.chat.example/
&resource=https://mcp.chat.example/
&subject_token=<ID_TOKEN>
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&client_id=<CLIENT_ID>
&client_secret=<SECRET>

200 OK
{
  "issued_token_type": "urn:ietf:params:oauth:token-type:id-jag",
  "access_token": "<JWT_ID_JAG>",
  "token_type": "N_A",
  "expires_in": 300
}

Two parameters carry the precision that makes this safe: audience must be the issuer identifier of the MCP server’s own Authorization Server (not the MCP server itself), and resource must be the MCP server’s resource identifier. The IdP binds the ID-JAG to both before it ever leaves the building. Step two is a JWT Bearer grant (RFC 7523) against the MCP server’s own Authorization Server, presenting that ID-JAG as the assertion:

POST /token HTTP/1.1
Host: auth.chat.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=<ID_JAG_TOKEN>
&client_id=https://client.example.com/client.json

200 OK
{
  "token_type": "Bearer",
  "access_token": "<MCP_ACCESS_TOKEN>",
  "expires_in": 86400
}

Two details worth flagging for anyone who’s read our OAuth 2.1 reference. First, the resulting access token is still audience-restricted to this one MCP server — EMA reuses OAuth 2.1’s own resource-binding discipline rather than inventing a looser rule for the enterprise path. Second, the client_id in that second request is a URL, not an opaque string — the Client ID Metadata Document pattern our OAuth 2.1 piece covered as an emerging proposal ships here as a working part of the flow. And the numbers matter operationally: in the spec’s own example the ID-JAG lives for 300 seconds (five minutes, intentionally too short to be worth stealing) while the resulting MCP access token lives for 86,400 seconds (24 hours) — actual lifetimes are each IdP and MCP Authorization Server’s own choice, not a spec mandate.

EMA vs OAuth 2.1

These are not competing specs; they answer different questions and stack on top of each other. OAuth 2.1 for MCP is the base layer every remote MCP server ships: PKCE, Dynamic Client Registration, RFC 9728/8414 discovery, one human clicking “allow” once per client-server pair. EMA is an additive extension that a client and server can both opt into on top of that same foundation. It doesn’t touch PKCE, doesn’t remove DCR, and doesn’t change how tokens are validated at the server. What it changes is who makes the consent decision and how the client gets there: instead of a human clicking through a browser redirect for every server, the IdP’s policy engine makes the call once, and the ID-JAG/JWT-bearer relay carries that decision to the server’s own OAuth stack.

Practical rule of thumb: if you’re one developer connecting your own Claude Desktop to your own Linear account, plain OAuth 2.1 with DCR is already frictionless — you are the admin and the user. EMA earns its keep at the point where those two roles split: a security team deciding what a hundred employees can connect to, and employees who shouldn’t have to know or care.

Who’s shipping it

An extension is only as useful as who implements it. As of this writing, per the official announcement:

• Identity provider: Okta, via its Cross App Access (XAA) product — XAA is Okta’s branded implementation of the ID-JAG mechanism, and the origin point the extension grew out of.
• Clients: Claude, Claude Code, and Cowork through Anthropic’s shared MCP layer (admins authorize a server once and it’s live across all three), plus VS Code.
• Servers: Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase, with Slack actively adding support.

Two of those server-side adopters are in our catalog today with the lightweight detail card — useful if you want to see what each looks like before deciding whether EMA matters for your stack:

Supabase MCP Serversupabase-community

Official1-Click ReadyRemote

Connect Supabase projects to AI with Supabase MCP Server. Standardize LLM communication for secure, efficient development and data management.

databases2.6k52

Atlassian is also on the adopter list and published its own engineering write-up on wiring XAA and ID-JAG into Rovo MCP — worth reading if you run Atlassian Cloud and want the implementation-level detail (linked in Sources below).

What EMA doesn’t govern

It’s tempting to read “the IdP authorized this connection” as “this session is safe.” That reading is wrong, and it’s worth stating plainly before anyone builds a deployment plan around it. EMA is a connection-level control: it answers whether this user’s client is allowed to reach this server, at what scope, at the moment the token is issued. It has no visibility into what happens after that — the IdP is not in the loop for the individual tools/call requests that follow.

Independent auth researcher Ehsan Hosseini put this sharply in his write-up of the spec: EMA “answers can this user connect this client to this server, and which scopes? It never answers should this specific action run, right now, on this resource?” His example is the one that should worry anyone deploying agents with write scopes: a release agent with a validly issued EMA token can still, mid-run, delete a branch it shouldn’t or act on a repo outside its assigned task. A correctly issued token doesn’t prevent that. Nothing in EMA does.

The practical takeaway: EMA replaces your consent-screen sprawl, not your policy-enforcement layer. If you’re giving agents write access to anything destructive, you still need a runtime decision point — tool-approval prompts, scoped credentials per task, or a gateway that inspects calls — sitting between “this client is authorized” and “this specific call should execute.”

How to enable it

Three parties have to opt in independently, and missing any one of them silently falls back to standard per-server OAuth — there’s no error, the user just sees the normal consent screen instead.

1. Identity provider support. Okta is the only shipped option today. If your org runs a different IdP, EMA has nothing to attach to yet.
2. Client declares the capability. During initialize, a supporting client advertises the extension:

   {
     "capabilities": {
       "extensions": {
         "io.modelcontextprotocol/enterprise-managed-authorization": {}
       }
     }
   }

3. Server declares it requires EMA. The MCP server publishes the same extension in its authorization metadata so clients know to skip the interactive redirect and go straight to the ID-JAG exchange.

From there it’s an admin-console job, not a developer one: an IT admin authorizes the server for the org inside the IdP, scoped to whichever groups or roles should have it. For the full implementation checklist (client, server, and authorization-server responsibilities), the spec’s implementation guide is the source of truth, and the ext-auth repository carries reference code. Two mistakes worth naming before you start: assuming a client supports EMA because a different Anthropic surface does (check the client matrix per product, not per vendor), and forgetting that account linking depends on the ID-JAG’s subject claim first and email only as a fallback for accounts that predate EMA.

Limits & who it’s for

What to know before you plan around this:

• One identity provider today. Okta is the only shipped IdP integration. The extension is additive, not universal — an org on a different IdP has no EMA fallback path until that IdP ships support.
• Short-lived by design. The spec’s own example issues a five-minute ID-JAG and a 24-hour access token; treat both as illustrative, not guaranteed, since each IdP and MCP Authorization Server sets its own values.
• Connection-level only. As covered above, EMA has no opinion on individual tool calls — pair it with your own runtime guardrails.
• Support varies by product, not vendor. “Anthropic supports EMA” means Claude, Claude Code, and Cowork specifically via the shared MCP layer — verify any other client individually against the spec’s client matrix.

Community signal

Three reactions that capture how this landed outside the announcement itself.

The verdict

The bigger picture

EMA didn’t appear from nothing. It traces back to SEP-990, the original proposal to let enterprise IdPs control MCP access, and Okta’s XAA product, which shipped in late 2025 as the first working implementation of the idea before the MCP maintainers folded it into a formal extension. A standing Enterprise-Managed Authorization interest group now owns its evolution, which is where Slack’s pending support and any future IdPs beyond Okta will surface first.

It also lands in the same season as a bigger protocol shift: our MCP 2026-07-28 release-candidate breakdown covers six separate SEPs hardening MCP’s base OAuth 2.1 layer — issuer validation, OIDC application-type declaration, client-credential binding — the exact foundation EMA’s ID-JAG exchange sits on top of. Read that one for where the base protocol is headed; read this one for how enterprises provision access on top of it. Together they’re the clearest signal yet that 2026 is the year MCP stopped being a single-developer tool and started being infrastructure a security team has to sign off on.

Frequently asked questions

Glossary

Sources

Primary

• Enterprise-Managed Authorization: Zero-touch OAuth for MCP — MCP Blog, June 18, 2026.
• Enterprise-Managed Authorization — modelcontextprotocol.io extension docs.
• Full technical specification — modelcontextprotocol/ext-auth, stable track.
• Enterprise-Managed Authorization interest group charter
• Centrally manage authorization for MCP connectors — Claude by Anthropic.
• Cross App Access extends MCP to bring enterprise-grade security to AI agent interactions — Okta Newsroom.

Press

• AI Model Context Protocol Adds Centralised Auth for Enterprise — Matt Saunders, InfoQ, July 6, 2026.
• MCP gets its missing enterprise authorization layer — The New Stack.
• MCP Enterprise Authorization Goes Stable — TechTimes.
• How We Brought Enterprise-Managed Authorization to Rovo MCP with XAA and ID-JAG — Inside Atlassian engineering blog.

Community & critical voices

• Hacker News discussion on the announcement thread “Zero-Touch OAuth for MCP.”
• Enterprise-Managed Authorization for MCP: what it actually does, and what it leaves to you — Ehsan Hosseini.

Internal links

• /blog/oauth-21-for-remote-mcp-servers — the base protocol EMA builds on
• /blog/mcp-2026-07-28-release-candidate — the auth-hardening SEPs landing the same season
• /blog/what-is-mcp — protocol primer
• /blog/mcp-security-… — OWASP MCP Top 10 and the runtime threat model
• /servers/linear · /servers/supabase-mcp-server
• /clients/claude-code · /clients/vscode
• /servers — browse all 3,000+