Anthropic Kills Repetitive Login Screens for Claude's MCP Connectors

Anthropic is rolling out Enterprise Managed Auth (EMA), which lets administrators configure eligible MCP connectors through an organization’s identity provider. Members covered by the policy can use their existing Claude single sign-on session, avoiding a separate OAuth consent flow for every connector.

The Model Context Protocol (MCP) lets AI clients call external tools and retrieve data from services such as Linear, Notion, Figma, and Datadog. Per-user OAuth flows create repeated setup work and leave administrators managing grants across multiple clients and services. EMA moves connector eligibility to a central policy and gives authorization servers a standardized token exchange to implement.

One policy, one token path

When an eligible user accesses a protected connector, Claude presents its authorization server with a signed JSON Web Token that attests to the user’s identity. The exchange follows this sequence:

1. The user signs in to Claude through the organization’s single sign-on system.
2. Claude requests an Identity Assertion JWT Authorization Grant, or ID-JAG, from the trusted issuer.
3. The issuer evaluates group membership, conditional access rules, and other organizational policies.
4. Claude sends the signed assertion to the connector’s authorization server using the JWT bearer grant.
5. The authorization server validates the assertion and returns an access token for the MCP server.

The exchange runs through back-channel requests, so it requires no browser redirect or individual consent screen. The connector continues to calculate scopes and enforce application-level permissions after authentication.

Two issuers, same exchange

EMA supports two trust models, allowing organizations to use a compatible identity provider or delegate assertion issuance to Claude.

In the Claude-issued mode, Claude vouches for signed-in organization members. Administrators can enable a compatible connector once and make it available to members covered by the workspace policy.

The first beta roster

Claude’s trusted-issuer mode is available in beta on Team and Enterprise plans. The initial group of compatible plugins spans common development and business systems:

• Analytics and marketing: Amplitude, Mixpanel, Semrush
• Planning and documentation: Atlassian, Linear, Notion
• Observability and incidents: Datadog, PagerDuty
• Files, design, and notes: Dropbox, Figma, Granola
• CRM and sales: HubSpot, Apollo.io
• Backend infrastructure: Supabase

The protocol on the wire

EMA uses the open MCP extension identified as io.modelcontextprotocol/enterprise-managed-authorization . The extension builds on the IETF draft Identity Assertion JWT Authorization Grant and the JWT bearer grant defined by RFC 7523.

The ID-JAG serves as signed evidence of the user’s identity and organizational context. The connector’s authorization server verifies that evidence before issuing its own access token, which remains the credential used to call the MCP server.

The client sends the assertion, registered client ID, requested scopes, and MCP resource to the connector’s token endpoint:

A connector checklist

Connector developers need to update the authorization server, tenant configuration, and client registration model before Claude can offer managed authentication.

1. Publish grant support. Add urn:ietf:params:oauth:grant-type:jwt-bearer to grant_types_supported in the authorization server’s metadata.
2. Configure trusted issuers per tenant. Maintain an allowlist of accepted issuer URLs, resolve signing keys through trusted issuer metadata, cache the JWKS, and handle key rotation.
3. Validate every assertion. Verify the signature and expected algorithm, then check iss , aud , exp , sub , and client_id . Requests from unlisted issuers should return invalid_grant .
4. Map identity to permissions. Resolve the validated subject to a local account and calculate scopes with the connector’s existing authorization policy.
5. Register Claude with a stable client ID. Use Anthropic-held client credentials or a Client ID Metadata Document. Dynamic Client Registration is unsupported because the IdP places a fixed client_id in each assertion.

Servers can retain lazy authorization behavior. When a protected tool call returns 401 with a valid WWW-Authenticate header, Claude can perform the silent JWT bearer exchange and retry the request. A failed policy check or token exchange leaves the connector disconnected.

The IdP becomes the policy gate

Central policy simplifies onboarding and offboarding because removing an account or group assignment prevents the IdP from issuing new assertions. Existing connector access tokens may remain valid until they expire or are revoked, so authorization servers still need suitable token lifetimes and revocation controls.

Identity providers can apply group membership, device posture, location, and other conditional-access signals before issuing an ID-JAG. Connector authorization servers remain responsible for tenant isolation, resource permissions, scope calculation, audit records, and access-token security.

The surrounding ecosystem includes Okta Cross App Access, Auth0, Ping Identity, Descope, WorkOS AuthKit, Stytch, Scalekit, Keycloak, and Janssen. Support varies by product version and by whether a system issues or accepts assertions. Okta’s Cross App Access playground can exercise the flow without a Claude organization and displays decoded tokens for inspection.

Beta boundaries

Claude’s trusted-issuer mode remains a Team and Enterprise beta, and auto-connect appears only after an organization enables a compatible connector and configures the required trust. Individual Pro accounts do not receive organization-managed connections.

Connectors built around Dynamic Client Registration must add pre-registered credentials or a Client ID Metadata Document. Authless MCP servers receive no benefit from EMA because they have no authorization server or token exchange. Connector teams should verify issuer support, registration requirements, token lifetime, and lazy-auth behavior before advertising auto-connect compatibility.