Every remote MCP server used to mean its own OAuth consent screen. EMA, stable since June 2026, turns that into a single SSO decision. Here is how it works.
We have argued before that OAuth is where remote MCP servers break in production. The single worst part of that experience for a team is the consent tax: every person has to click through a separate authorization screen for every remote MCP server they connect to. Multiply a dozen servers by a hundred employees and it stops being a minor annoyance. MCP's Enterprise-Managed Authorization (EMA) extension, which went stable on June 18, 2026, is the answer to exactly that problem.
EMA turns per-server OAuth consent into a one-time, org-managed decision. Instead of every employee authorizing every server individually, the company's identity provider grants access once, during single sign-on, and approved servers connect automatically on first login. The MCP announcement calls it "zero-touch setup." It fixes three things at once:
The mechanism has a name: the Identity Assertion JWT Authorization Grant, or ID-JAG. The flow is short:
The per-server consent screen never appears, because the organization already made the decision at the identity-provider level. Access is scoped to the user's existing groups and roles in the identity provider, so people only reach the servers their role allows.
EMA is an enterprise feature, and the name is honest about that. It requires a supported identity provider. At launch that means Okta, using the XAA protocol. If you do not have an identity provider that speaks it, you are still on standard per-server OAuth for now. This is not a solo-developer convenience; it is the thing that makes running remote MCP servers across a whole company tolerable.
Support arrived broad for a day-one release:
That is a meaningful chunk of the remote-MCP ecosystem lined up behind the extension on the same day it went stable.
If you run a single MCP server for yourself, EMA changes nothing for you yet, and you will keep doing the normal OAuth dance. Where it matters is the case we keep coming back to: a team pointing many people at many remote MCP servers. That is exactly where the consent-screen tax compounds, and it is the situation Yaw MCP exists to manage. EMA does not replace orchestration: you still decide which servers to run and how their tools land in context. It removes the authorization friction that made "connect the whole team to the whole fleet" a non-starter.
EMA is the enterprise half of the fix for the OAuth problem we flagged earlier. It does not simplify a solo developer's setup, and it ties you to a supported identity provider (Okta first). But for an organization, it turns "every person authorizes every server" into a single SSO decision governed by the identity provider you already run. If remote MCP servers are going to live inside real companies, this is the plumbing that makes it work.
Published by Yaw Labs.