MCP Auth Example: 2026 Enterprise Authorization in Practice

The Enterprise-Managed Authorization (EMA) extension for the Model Context Protocol went stable on June 18, 2026, and it fundamentally changes how organizations provision access to AI agent tooling. If you’ve been tracking MCP’s explosive growth — combined Python and TypeScript SDK downloads crossed 97 million monthly by late 2025, per MarkTechPost — you’ve probably noticed that authentication has been the missing piece preventing enterprise rollouts. EMA fills that gap, but not in the way most teams expect.

Here’s the core tension: EMA solves connection provisioning beautifully while leaving runtime authorization entirely to implementers. Understanding where its authority stops is the difference between a secure deployment and a false sense of safety.

The Per-User Problem EMA Replaces

Before EMA, the standard MCP authorization model was per-user and per-server, requiring every employee to manually authorize every server individually. Security teams had no central policy enforcement, no audit trail, and no way to separate work from personal accounts. As the Model Context Protocol blog documents, this created a structural gap where access was whatever each user authorized on their own.

The practical consequences were severe. Onboarding meant manually connecting service after service. Offboarding required revoking access server by server. And because the flow required interactive account selection, users could accidentally link personal accounts to work tools with zero IT visibility.

EMA inverts this model. Organizations now centrally manage MCP server access through their identity provider, giving end-users zero-touch setup where approved servers connect on first login with no per-app OAuth consent screens required, per Claude’s announcement. Admins define policy once; users inherit access through IdP groups and roles they already have.

How the ID-JAG Flow Works Under the Hood

The technical mechanism behind EMA is the Identity Assertion JWT Authorization Grant (ID-JAG), an IETF draft standard. The flow uses three standard pieces, as detailed by Ehsan Hosseini:

OIDC/SAML login — The user authenticates through corporate single sign-on
RFC 8693 token exchange — The client exchanges the IdP assertion for an ID-JAG
RFC 7523 JWT bearer grant — The authorization server issues an access token

The user never sees a per-server consent screen. The client silently acquires tokens for every approved server behind that single login event. Revocation at the IdP takes effect everywhere immediately.

Okta is the launch identity provider via Cross App Access, with support for additional IdPs expected. Compatible clients include Claude, Claude Code, and Visual Studio Code. Supported servers at launch include Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase, per Claude’s blog.

Where EMA’s Authority Stops: The Governance Horizon

Here’s where I want to be precise about what EMA does and doesn’t do, because this distinction trips up security teams. EMA governs the connection — whether a specific client can reach a specific server for a specific user. What it cannot govern is the runtime action: whether a specific tool call, in a specific context, should go through.

The spec is explicit that the IdP never sees the MCP traffic. As Hosseini’s analysis notes, the IdP’s visibility is limited to the moment the access token is issued and does not extend to the MCP traffic between client and server. Runtime, per-action authorization is the layer EMA leaves entirely to you, and it lives in the data path.

Think of it this way: your IdP audit logs confirm that Alice in engineering can access the Linear MCP server. They do not show you whether her autonomous agent actually created 47 issues, read sprint data, or did nothing at all. That blind spot is structural, not a bug. Organizations treating EMA as a complete security control will discover their audit trails have a critical gap at the per-action level.

This is what I call the Authorization Horizon pattern: centralized connection governance via IdP on one side, distributed runtime governance across MCP servers and gateways on the other, with a gap in the middle where most of the actual risk lives.

MCP 2.0’s Stateless Shift Changes the Security Model

The upcoming MCP 2026-07-28 specification — final version shipping July 28, 2026 — removes protocol-managed sessions entirely. The initialize/initialized handshake is gone. The Mcp-Session-Id header is gone. Every request now carries what the server needs in a _meta field, making the protocol stateless at the layer that previously required sticky sessions and shared session stores, per the official spec blog.

This eliminates session hijacking as a protocol-level attack vector. But Akamai’s security analysis identifies a new risk surface: the spec introduces tracking identifiers and state objects that the server hands to the client, which passes them back to resume a workflow. If a server uses predictable tracking IDs or fails to validate returned state objects, an attacker could guess or alter those values to hijack another user’s active workflow. The specification warns developers to verify those objects but does not set a standard for how.

The tradeoff is deliberate. Stateless protocols scale horizontally behind ordinary load balancers — a major operability win. But security decisions the protocol used to enforce now fall to individual server developers, creating the same implementation-dependent risk pattern that EMA pushes to the data path.

What Spec-Compliant Authentication Actually Requires

For teams building or deploying remote MCP servers today, the spec mandates a specific set of OAuth 2.1 capabilities. Per MarkTechPost’s breakdown:

OAuth 2.1 with PKCE mandatory for all remote servers (not optional)
HTTPS required on all endpoints
RFC 8414 authorization server metadata must be discoverable
RFC 9728 Protected Resource Metadata must be exposed
RFC 8707 Resource Indicators must be validated to prevent token audience confusion

Client registration follows a priority order: pre-registration if you have a client_id, Client ID Metadata Documents (CIMD) as the should-level preferred path, and Dynamic Client Registration (DCR) as a may-level fallback. CIMD lets a client host a JSON document at an HTTPS URL and use that URL as its client_id — no per-server registration step required.

The MCP 2026-07-28 spec also mandates OAuth 2.1 with PKCE for all remote servers, per the release candidate announcement. If your servers don’t meet these requirements by the July finalization, you’ll be running on deprecated protocol versions within the 12-month deprecation window.

The Gateway Layer MCP Itself Doesn’t Provide

MCP provides no built-in authentication, rate limiting, audit logging, or access control, per Requesty’s gateway comparison. In production, that necessitates an external gateway to centralize security, observability, and governance. Without one, every agent connects to every MCP server directly — meaning every agent needs every credential, and a single compromised agent exposes everything.

The cost calculus is worth examining. Self-hosting an MCP server runs $40–120 per month on a small VPS. Cloudflare’s MCP Gateway scales at $0.50 per million requests with built-in authentication, audit, and DDoS protection. For teams running high-volume agent workloads, the gateway model often wins on both cost and security posture.

Authentication Platforms Compared

Platform	Pricing Model	MCP-Specific Support	Enterprise Features	Best For
Auth0	Free up to 25,000 MAU; Essentials at $35/month for 500 MAU; Professional at $240/month	OAuth 2.1 authorization server, Token Vault for agentic workflows	SSO, SCIM, MFA, RBAC (higher tiers)	Teams already in Okta ecosystem
WorkOS	Contact for pricing	AuthKit as OAuth 2.1 AS for MCP, FGA for tool-level permissions	SSO, SCIM, Admin Portal, audit logs	Enterprise teams needing fine-grained auth
Cloudflare	$0.50/million requests	Managed MCP Gateway with built-in auth	DDoS protection, audit, global edge	High-volume, cost-sensitive deployments
Okta (EMA)	Via existing IdP license	Cross App Access for zero-touch provisioning	IdP-native policy, group-based access	Organizations already standardizing on Okta

Auth0’s pricing escalates quickly for multi-agent systems. One developer reported quotes of $96,000/year for 50,000 MAU with MFA, RBAC, SAML, and custom domains — a pattern that suggests Auth0’s tiered model penalizes the high-volume M2M authentications that agent fleets generate. The global IAM market, valued at approximately $25 billion in 2026 with a 13.7% CAGR, reflects surging demand that current pricing structures aren’t designed to accommodate.

The Implementation Gap Most Teams Miss

Here’s a number that should concern you: only 18% of MCP server deployments implement any form of access scoping for tool permissions, and 53% of MCP servers expose credentials through hard-coded values in configuration files, per WorkOS data cited by NHI Management Group.

This is the gap between protocol capability and implementation reality. The spec gives you the tools to do authentication correctly — OAuth 2.1, resource indicators, CIMD, PKCE. Most deployments simply don’t use them. If you’re rolling out MCP in an enterprise context, your first audit should be checking whether your servers meet the spec’s baseline requirements, not whether you’ve enabled EMA.

For deeper implementation guidance, our companion posts on building a Node.js MCP server and building a Python MCP server cover the practical steps for getting authentication right at the server level, including the critical changes required before the July 2026 spec finalizes.

Where This Leaves You

EMA is connection provisioning, not authorization governance. It solves the onboarding friction and central audit problem at the IdP layer, which is genuinely valuable. But it does not — and structurally cannot — tell you what your autonomous agents are actually doing with their access once tokens are issued.

The teams that get this right will layer three things: EMA for centralized connection governance, an MCP gateway for runtime policy enforcement and audit logging, and per-tool scope validation in the data path where the actual risk lives. Skip any one of those layers and you’re either ungoverned or unscalable.

The question isn’t whether your organization will adopt MCP — with 97 million monthly SDK downloads and Gartner projecting 40% of enterprise applications will include integrated AI agents by end of 2026, that ship has sailed. The question is whether your authentication architecture will be ready when your security team asks what your agents actually did last Tuesday.