Enterprise-managed auth is GA and your MCP server needs a new grant type

Anthropic made enterprise-managed auth for MCP connectors generally available on August 24, 2026. Admins on Claude Team and Enterprise plans provision connector access centrally through their identity provider, and users get their tools connected without an individual OAuth trip.

The admin console is the least interesting part of this for anyone shipping an MCP server. The flow enterprise customers will use skips the OAuth ceremony you built. Claude presents your authorization server with a signed JWT issued by the customer's identity provider and gets an access token back in a single back-channel request: no browser redirect, no per-connector consent page. Underneath it is the Identity Assertion JWT Authorization Grant (ID-JAG), obtained from the IdP during single sign-on and exchanged at your token endpoint.

What actually shipped

The MCP Enterprise-Managed Authorization extension is now stable, and the MCP maintainers describe it as being adopted by Anthropic, Microsoft, Okta, and a growing number of MCP servers. On the Claude side, GA added Datadog, Notion, and Slack support, with Exa, Miro, and Zoom named as coming soon, on top of the existing Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase connectors. Okta is the identity provider supported at launch, with more said to be coming. Access is consistent across Claude chat, Claude Code, and Cowork.

This reaches past Claude. VS Code 1.123, released June 3, 2026, shipped enterprise-managed MCP authentication in preview: admins configure the IdP through a policy-managed mcp.enterpriseManagedAuth.idp setting, and individual servers opt in with "enterpriseManaged": true in their oauth block.

Hubspot, Ramp, and Webflow are among the customers rolling it out. Ramp's IT engineering lead for AI gives the clearest picture of what admins are buying:

“Before enterprise-managed auth, onboarding a new hire to their full toolkit meant a queue of per-connector OAuth approvals. Now they log in to Claude on day one already connected — 2,000 employees, provisioned through Okta, zero extra steps.”

— Cameron Leavenworth, Staff IT Engineer, AI, Ramp

Removing the consent screen

Every MCP server that shipped OAuth put some amount of product logic on the consent page. Which account. Which workspace. Which scopes. Under enterprise-managed auth that page never renders, and nobody is sitting at a keyboard to click approve. Even the lazy-authentication path changes: when your server returns 401, Claude normally shows the inline Connect card, but for an organization with EMA configured it runs the silent JWT bearer exchange and retries the tool call without prompting.

The decisions the consent screen used to collect now have to come from claims. ID-JAG tokens carry scope and resource information that your server uses to determine who the employee is and what they can reach, and your authorization logic is defined on those claims. Account linking gets its own rule: use the subject claim as the primary stable identifier and fall back to the email claim to match accounts created before the org configured enterprise-managed auth. Get that mapping wrong and you silently fork a user into two identities on their first day.

One category of server gets nothing here. A fully authless MCP server never returns 401, so there is no point at which Claude can exchange an assertion, and enterprise-managed auth does not apply.

Dynamic client registration is off the enterprise path

Anthropic's connector docs put the constraint plainly:

Dynamic Client Registration (DCR) is not supported with Enterprise Managed Auth. The identity provider stamps a fixed client_id into every assertion it issues, so your authorization server must already recognize that client before the first assertion arrives. A client created on the fly through DCR cannot satisfy this requirement because its identifier will never match the value in the assertion.

Your authorization server registers Claude with either Anthropic-held client credentials or a Client ID Metadata Document instead. VS Code moved the same direction in the same release, letting users pin a pre-registered client ID in mcp.json rather than registering a new client each time:

  
"my-mcp-server": {
    "url": "https://mcp.example.com/mcp",
    "type": "http",
    "oauth": {
        "clientId": "your-client-id"
    }
}
  

‍If your server relies on DCR alone today, nothing breaks and nothing improves. Your metadata never advertises the JWT bearer grant, so Claude never offers enterprise-managed auth for your connector, and every user keeps doing the interactive flow.

DCR was the ergonomic story for remote MCP: any client could show up and register itself. That property is what an enterprise deployment refuses to accept, because a client identity nobody vetted cannot be named in a policy. That's the tradeoff: a governable deployment needs a stable client identity.

What your authorization server has to accept

Four concrete requirements, none of them large on their own.

Support the JWT bearer grant, and advertise it. Your token endpoint must accept urn:ietf:params:oauth:grant-type:jwt-bearer and list it in the grant_types_supported array of your RFC 8414 authorization server metadata:

  
{
    "issuer": "https://auth.example.com",
    "token_endpoint": "https://auth.example.com/token",
    "grant_types_supported": ["authorization_code", "refresh_token", "urn:ietf:params:oauth:grant-type:jwt-bearer"]
}
  

‍Claude reads that metadata to decide whether to offer enterprise-managed auth to a customer, and the grant type has to be listed for the feature to appear at all, even if your token endpoint would happily accept the request.

Handle the token request either way. Claude sends a form-encoded POST carrying the assertion:

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

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJhbGciOi...
&client_id=your-registered-client-id
&scope=openid profile
&resource=https://mcp.example.com
  

‍The resource parameter (RFC 8707) is set to your MCP server URL whenever the customer's IdP can forward it, and some configurations cannot. Accept the request with or without it, and use it for audience binding when it is there.

Keep a per-tenant issuer allowlist. Your authorization server is responsible for an explicit list of trusted issuer URLs per tenant, and must reject an assertion whose iss is not on that tenant's list with invalid_grant, valid signature or not. A correctly signed JWT from someone else's IdP is still someone else's IdP.

Pick a shorter token lifetime than you used to. You set the access token lifetime, the customer's IdP sets the assertion lifetime, and Anthropic controls neither. Because Claude holds a refresh token from the IdP and can mint fresh assertions without user interaction, a one-hour access token no longer means an hourly login. Anthropic's docs leave the lifetime to your security policy, but the deprovisioning math argues for going short: a shorter lifetime means a deprovisioned employee's connector access expires fast instead of riding an old token.

Where the friction moves

Per-user OAuth was a tax, and taxes shape behavior. Supabase's CISO described the pre-EMA state of their own connector plainly:

“The only way to use Supabase through Claude was to be an org owner or hand out Personal Access Tokens to everyone on your team. Enterprise-managed auth fixes that: your IdP controls access and roles, so builders can use Claude to explore and query their data without IT compromising on security to get there.”

— Bil Harmer, CISO, Supabase

Adoption of your connector stops being a per-user decision and becomes an admin one, made in a console you never see, against an allowlist your name has to be on. Anthropic lets developers add enterprise-managed auth to their own third-party connectors in the Claude directory, and links to your admin setup documentation from the Claude admin console when someone configures your connector. That doc link is now part of your onboarding funnel.

The counterargument deserves stating. This is early. Okta is the only identity provider supported at launch, and VS Code's own release notes call ID-JAG an emerging standard that isn't widely adopted yet, while betting that it's the future of cross-app authorization. Anthropic's connector-developer docs still carry a register-interest form even as the feature is announced GA. Plan on running both paths for a while: interactive OAuth stays the flow for every customer whose IdP can't issue assertions yet, and the silent exchange only takes over for organizations that have EMA configured. Two code paths, two sets of test cases, and only one of them is growing.

That is an argument about timing. The direction looks settled: enterprises are not going to keep approving AI-to-tool delegation one user at a time, and the extension underneath this stopped being a moving target.

Start where you can test

You do not need a Claude organization to try the flow. Okta's cross-app access playground at xaa.dev walks the full four-step exchange and lets you test your own requesting app or your own MCP server against it.

If your MCP server's auth already runs on AuthKit, the assertion side is handled: WorkOS accepts ID-JAG assertions from enterprise IdPs and does the JWKS signature verification, audience and claims validation, policy enforcement, and scoped token issuance. We wrote up the full mechanism — the pattern is Cross App Access, the spec underneath it is ID-JAG — in our XAA explainer.

Either way, the work to schedule this quarter is small and specific: publish the grant type in your metadata, decide how Claude and other clients get a stable client ID at your authorization server, build the per-tenant issuer allowlist, and move the authorization decisions your consent screen used to make into claims mapping. Do that and the next admin who wants your connector switched on for 2,000 people can do it without ever emailing you about OAuth.