Zero-Touch OAuth for MCP

niyikiza1 pts0 comments

Enterprise-Managed Authorization: Zero-touch OAuth for MCP | Model Context Protocol BlogSkip to content<br>Table of ContentsPer-user auth is high friction<br>Authorize once, inherit everywhere<br>Early adopters<br>Get involved<br>Acknowledgements

The Enterprise-Managed Authorization extension is now stable. Organizations can centrally<br>manage authorization for MCP servers and end-users can access all connected MCP servers<br>through a single log in. The extension is being adopted by Anthropic, Microsoft, Okta and<br>a growing number of MCP servers.<br>The Enterprise-Managed Authorization (EMA) extension<br>is now stable. We&rsquo;ve heard from the community that authorization and repeated consent<br>prompts from connected MCP servers is one of the biggest pain points when it comes to<br>managing connectivity in enterprise environments. This extension helps address this.<br>EMA allows organizations to control MCP server access centrally through their trusted<br>identity provider. For end-users, this means a zero-touch setup: the MCP servers they<br>need are connected on first login, with no per-app OAuth and nothing to configure as a<br>one-off.

Per-user auth is high friction#<br>The standard MCP authorization model was designed to be user-scoped and bound to the<br>traditional interactive auth conventions. While this might work well for more general<br>consumer scenarios where individuals decide what touches their data, this doesn&rsquo;t quite<br>scale for enterprise deployments:<br>Every employee has to authorize every server individually : onboarding means<br>manually connecting service after service.<br>Security teams cannot enforce consistent policy : access is whatever each user<br>authorized, with no central control or audit trail.<br>Work and personal accounts blur together : there&rsquo;s no way to require a corporate<br>identity, so a user can connect a personal account to a work tool.<br>This combination of factors slows MCP adoption and pushes people toward brittle<br>workarounds. With no universal standard for preserving shared auth state, everyone<br>invents their own bespoke solution. The data and tools are available, but the per-user<br>authorization tax keeps most of them switched off.<br>Authorize once, inherit everywhere#<br>Enterprise-Managed Authorization<br>makes the organization&rsquo;s IdP the authoritative decision-maker for MCP server access.<br>Administrators define the policy once and users can authenticate with their existing<br>identity into the MCP host. The IdP can grant or deny access based on group membership,<br>role, and conditional access rules.<br>Under the hood, the client obtains an<br>Identity Assertion JWT Authorization Grant (ID-JAG)<br>from the IdP during single sign-on and exchanges it for an access token from the MCP<br>server&rsquo;s authorization server. The user is never redirected through a per-server consent<br>screen. Three properties fall out of that flow:<br>Authorize once, inherit everywhere: admins enable a server for the org. Users get<br>it automatically, scoped to the groups and roles they already have.<br>Centralized policy and audit: access decisions live in the IdP admin console, with<br>one auditable trail across every connector.<br>Removing personal/enterprise mixups: by removing the interactive account selection<br>step, it&rsquo;s much easier to prevent data flowing between personal and enterprise accounts<br>by mistake or compromise.<br>We see this as a brand new baseline for MCP in the enterprise. When users log in, their<br>client should be connected to the tools and data they&rsquo;re authorized to use with no extra<br>steps in between.<br>Early adopters#<br>This launch brought together three groups that collaborated closely on making the<br>implementation real:<br>Identity providers: Okta is the first supported identity provider. Organizations<br>using Okta can provision MCP access to supported servers through any supported client,<br>using<br>Okta&rsquo;s Cross App Access (XAA).<br>Clients:<br>Anthropic has implemented the extension<br>in its shared MCP layer for Claude. Admins can authorize MCP servers for users across<br>Claude, Claude Code, and Cowork. Additionally,<br>Visual Studio Code has also added support<br>for EMA right in the IDE.<br>Servers: Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase now support<br>EMA, with Slack and more actively adding support.<br>We&rsquo;re excited for more identity providers, clients, and servers to adopt<br>Enterprise-Managed Auth to help reduce the authorization-related fatigue and<br>significantly improve the security and observability posture for its implementers.<br>&ldquo;The momentum around MCP is incredible, but as we move toward an interconnected AI<br>workforce, security can&rsquo;t be an afterthought. By embedding the Cross App Access protocol<br>into MCP as the Enterprise-Managed Authorization extension, we turn identity into a<br>centralized governance plane and give security teams strict compliance control and users<br>a seamless, secure experience.&rdquo;<br>— Aaron Parecki, Director of Identity Standards, Okta

&ldquo;The Figma MCP brings the power of code and canvas together so teams...

authorization enterprise access rsquo servers identity

Related Articles