Zero-Touch OAuth for MCP: Beginner’s Setup Guide

Picture an IT admin closing their OAuth ticket queue on a Monday morning – not because they cleared the backlog, but because none of the per-connector authorization requests came in. The engineering hire who started that morning opened Claude, and Figma, Linear, Atlassian, Asana, Canva, Granola, and Supabase were already connected. No consent screens. No “please authorize” emails bouncing through IT. The admin didn’t touch a single approval.

That’s the end state EMA delivers. The mechanism is called Zero-Touch OAuth for MCP – officially the Enterprise-Managed Authorization (EMA) extension. It went stable on June 18, 2026, and the MCP community has been vocal for a reason: one Hacker News commenter argued the most valuable thing MCP does isn’t tools at all – it’s isolating the auth flow outside of the agent’s context window. EMA is what makes that idea work at company scale.

Walk backward from that Monday-morning result to what you actually need to configure.

Who this is actually for

You’re either (a) an IT admin tired of approving per-connector OAuth tickets one user at a time, or (b) a developer at a company where Claude (or VS Code) is rolling out and you want to understand what’s happening when connectors appear without any user action.

If you’re a solo user on Claude Pro: EMA is in beta for Claude Team and Enterprise plans only as of June 2026. Per-app OAuth is still your path for now.

What zero-touch OAuth for MCP actually is

Before EMA, every employee clicked through every OAuth consent screen for every MCP connector. Multiply that by 12 tools and 2,000 staff and the friction becomes a deployment blocker. Anthropic shipped EMA as the first implementation. MCP itself is now a Linux Foundation project under the Agentic AI Foundation (donated December 2025), so this is governed standard, not a vendor lock-in.

Under the hood it’s not magic. It’s an IETF draft called Identity Assertion JWT Authorization Grant (ID-JAG) – Okta’s Cross App Access protocol formalized into the MCP spec. The flow:

1. User logs into Claude via SSO (your IdP – currently Okta only).
2. Claude requests an ID-JAG from the IdP using OAuth Token Exchange.
3. IdP checks: “Is this user in a group allowed to use Figma’s MCP server?” If yes, it issues a signed JWT.
4. Claude hands that JWT to the MCP server’s authorization server, gets an access token back, done.

The JWT is signed with the same private key the IdP uses for regular SSO ID tokens, so any MCP server that already trusts your IdP can verify it without extra setup. No consent screen appears anywhere in that chain.

Setting it up: the admin path

Okta as your IdP is a hard requirement right now. (If you’re on Azure AD or Google Workspace, jump to the limitations section – you’ll be waiting.) Here’s the order of operations for Claude Enterprise admins.

Step 1: Connect Okta to Claude

In the Claude admin console, link your Okta tenant as the IdP. This is the same SSO setup you probably already have for normal Claude login. EMA piggybacks on it.

Step 2: Pick which MCP connectors to enable

At launch you have seven options: Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase. Slack support is in progress as of June 2026 per Anthropic’s announcement. Enable only what your org actually uses.

Step 3: Scope by group in Okta, not in Claude

This is the part that catches first-timers. Access assignment happens in your Okta admin console using the same groups you already use for everything else. Engineering gets Linear and Supabase. Design gets Figma and Canva. Sales gets Asana. The IdP becomes the single source of truth – Claude just reads whatever Okta says.

Step 4: Test with one user, then roll out

Pick a willing victim, have them log out of Claude completely, and log back in. The connectors they’re entitled to should appear without any consent dance. If they don’t – check group assignment in Okta first, then JWT signing config.

Migration heads-up: Don’t move everyone at once. Existing users who already authorized connectors the old way may have stale per-user tokens floating around. Run a small pilot group first: have them disconnect old OAuth connections, then re-login under EMA. The docs don’t spell out automatic migration behavior – better to force a clean state than discover the conflict mid-rollout.

The developer angle: building an EMA-compatible MCP server

If you maintain an MCP server and want enterprise customers to deploy it, EMA support is the baseline expectation for enterprise customers. The spec is open – your server acts as an OAuth 2.1 resource server, but now needs to accept and verify the ID-JAG-derived access tokens.

At a minimum your server has to:

# Pseudocode - what your MCP server must do
1. Expose /.well-known/oauth-protected-resource metadata
2. Accept Bearer token in Authorization header (NEVER query string)
3. Validate token audience matches your canonical URI (RFC 8707)
4. Verify JWT signature against the IdP's JWKS
5. Return 401 + WWW-Authenticate on missing/invalid token

The audience validation matters more than it looks. The spec is explicit: servers must not accept tokens issued for other resources. Get that wrong and you’ve built a confused deputy vulnerability into your server by design.

Honest limitations (the part nobody else lists clearly)

The May 2026 NSA advisory on MCP security flagged a specific attack surface: unmanaged agent connections using hardcoded credentials and long-lived personal tokens. EMA closes that gap. What it doesn’t address is fine-grained authorization – once an agent holds a token, the token’s scope determines what it can do, and scope design is entirely on you.

The honest reframe

Here’s something the official posts won’t quite say out loud. If you read the Hacker News reaction thread, a recurring take is that MCP’s real long-term value might be standardized auth – not the tools, not the protocol verbs, not the resources. The auth gateway might be the whole product.

Whether you agree or not, EMA is the moment that hypothesis gets tested at enterprise scale. Worth watching which IdPs get added next – that list will tell you a lot about where MCP’s actual gravity is pulling.

FAQ

Does Zero-Touch OAuth for MCP work with Azure AD or Google Workspace?

Not at launch. Okta only. Anthropic says more IdPs are coming but hasn’t given a date as of the June 2026 release.

What’s the difference between EMA and regular MCP OAuth 2.1?

Regular MCP OAuth is still there – per server, interactive, requires a user to click through. EMA is an extension that sits on top: an admin pre-authorizes connectors via IdP group policy, and the IdP issues a JWT on login that the MCP server accepts directly. The underlying spec is unchanged. Think of it as the enterprise overlay vs. the consumer path – same road, different on-ramp.

What happens if my IdP goes down?

Users with active tokens keep working until expiry. New logins fail. Token refreshes fail too – and because the MCP spec doesn’t guarantee refresh tokens (the authorization server decides whether to issue them), some sessions may be shorter than you’d expect. Set token lifetimes with that in mind before you’re debugging an outage at 2am.

What to do next

Claude Team or Enterprise with Okta: go to your admin console, link Okta if you haven’t already, and enable a single low-risk MCP connector first. Linear is a reasonable pick – read-heavy, easy to revoke. Test with one user. Once it works, expand. Azure AD or Google Workspace: subscribe to the MCP blog and wait – your turn is coming, just not yet.