Published:

Claude-issued auth for MCP connectors: auto-connect without an identity provider

In short: with Claude-issued auth, now in beta for Claude Team and Enterprise, Claude itself signs employees in to MCP connectors such as Atlassian, Notion and HubSpot, with no identity provider or SSO required. Atlassian has supported it since 3 November 2026. The catch: Claude only checks that someone is a member of your Claude organisation, not whether they signed in with SSO or MFA.

Anyone rolling out MCP connectors across an organisation knows the friction: every employee has to click "Connect" for every service and go through an OAuth login. Since June, Anthropic has offered enterprise-managed auth, where the organisation's identity provider handles that sign-in centrally. That variant became generally available on 24 August, but only with Okta, which left everyone else out. The Claude-issued variant closes that gap by making Claude itself the issuer of the identity assertion.

How does Claude-issued auth work?

Under the hood this is the official MCP extension io.modelcontextprotocol/enterprise-managed-authorization, built on an IETF draft, the Identity Assertion JWT Authorization Grant (ID-JAG). The client presents a signed identity assertion to the service's authorization server and receives an access token in return, with no OAuth consent screen for the user.

In the Claude-issued variant, Claude signs that assertion under an issuer URL that is unique to each Claude organisation (https://identity.anthropic.com/issuers/<issuer-id>). The admin copies that URL from Claude's admin settings and registers it as a trusted issuer in the connected service. For Atlassian, that means enabling enterprise-managed authentication for the Atlassian MCP server in Atlassian Administration, entering the issuer URL, and supplying the Atlassian site's cloudId as the tenant ID in Claude. Then run the test, pick roles and enable.

Anthropic lists fourteen connectors that support the Claude-issued variant: Amplitude, Apollo.io, Atlassian, Datadog, Dropbox, Figma, Granola, HubSpot, Linear, Mixpanel, Notion, PagerDuty, Semrush and Supabase. Slack, Asana and Canva support enterprise-managed auth through an identity provider, but are not on the Claude-issued list.

What does Claude-issued auth not check?

This is the part admins should read carefully. According to Anthropic's documentation, the assertion only states that the user is a current member of the Claude organisation, with their email address in lowercase. It does not say that the user signed in through the organisation's identity provider or used MFA, and it carries no group claims. Accounts are matched at the service by email address; anyone without a matching account simply sees the normal Connect button.

Three more details with operational consequences:

Our advice

Claude-issued auth effectively turns your Claude organisation into an identity provider for the connected services. That is fine, as long as you treat it like one. (1) If you run Okta, choose IdP-managed: your SSO, MFA and group policies then apply. (2) If you use Claude-issued, limit the connector to the roles that need it instead of the default "all roles", and keep Claude organisation membership as tightly managed as your directory. (3) Document offboarding as two steps: Claude and the service. For organisations subject to DORA or NIS2, this belongs in access management and in the register of ICT services. See also MCP security and, if you build your own server, building an MCP server.

What does this mean if you build your own MCP server?

To let your own MCP server work with Claude through enterprise-managed auth, the authorization server needs changes. Anthropic's documentation lists, among other things: advertise the urn:ietf:params:oauth:grant-type:jwt-bearer grant type in the server metadata, accept only ES256 and RS256, check that typ is oauth-id-jag+jwt, and accept each jti only once to prevent replay. Dynamic Client Registration does not work with enterprise-managed auth. WorkOS adds that the server should keep a per-tenant allowlist of issuers and reject assertions with an unknown iss.

The bigger picture

Enterprise adoption of MCP has mostly stalled on administration: who has access to which connector, and how do you revoke it? The enterprise-managed authorization extension, and now a variant that needs no identity provider of your own, moves that control from individual users to admins. That is a win for control and audit. It also shifts trust: whoever administers the Claude organisation now also controls access to Jira, Confluence and the CRM.

Sources

Frequently asked questions

What is the difference between IdP-managed and Claude-issued auth?

With IdP-managed auth, your own identity provider (currently only Okta) signs the identity assertion for a user who signed in to Claude through SSO; this variant is generally available. With Claude-issued auth, Claude signs the assertion itself, under an issuer URL unique to your organisation. It works without an identity provider or SSO, but is still in beta.

Does Claude-issued auth check MFA or SSO?

No. According to Anthropic's documentation, the assertion only states that the user is a member of your Claude organisation, along with their email address. It does not say whether the user signed in through your identity provider or used MFA, and it carries no groups. You need to enforce those safeguards elsewhere.

Which connectors support Claude-issued auth?

Anthropic lists fourteen connectors: Amplitude, Apollo.io, Atlassian, Datadog, Dropbox, Figma, Granola, HubSpot, Linear, Mixpanel, Notion, PagerDuty, Semrush and Supabase. Slack, Asana and Canva support enterprise-managed auth through an identity provider, but not (yet) the Claude-issued variant.

Last updated: