Claude plugins auto-connect for Team and Enterprise, even without Okta
Anthropic has added a second way for Claude Team and Enterprise organizations to connect workplace plugins for every member at once. Under the new Claude-issued option, now in beta, Claude itself vouches for the signed-in user to a connected service, so an organization no longer needs a compatible identity provider to skip the per-person sign-in and consent screens. Until now the only route to that experience was the identity-provider path, and the only identity provider supported for it was Okta.
The company announced the change on November 3, 2026 through its ClaudeDevs developer account, writing that users "can now auto-connect plugins when they log in to Claude, with MCP servers that accept Claude as a trusted issuer," and asking plugin builders to add support "so users get started faster and stay connected without re-authorizing." The Claude Help Center article that documents the feature, now titled "Auto-connect your organization's apps to Claude," was updated the same week and describes both identity sources, the admin setup and the limits of the beta.
The beta is narrower than the full feature. Anthropic's support page lists 15 connectors that work with managed authorization in general, but only seven of them accept Claude-issued sign-in today: Amplitude, Atlassian, Datadog, Figma, Linear, Notion and Supabase. Organizations that already run Okta keep the generally available identity-provider route, which the same page continues to describe as Okta-only, with more providers planned.
··········
HOW CLAUDE PLUGIN AUTO-CONNECT WORKED BEFORE NOVEMBER 3.
Anthropic first introduced enterprise-managed authorization for MCP connectors in June 2026 as a beta for Team and Enterprise customers, and made it generally available on August 24, 2026. The idea was to replace a two-step routine in which an admin enabled a connector for the organization and then each employee had to authorize it individually through an OAuth consent screen. With managed authorization, the admin authorizes a connector once, and members receive it automatically the first time they need it, based on the groups and roles they hold in the company's identity provider.
That design depended entirely on the identity provider. Okta was the only supported provider at launch and at general availability, which left companies that sign in through other directories with the old per-user flow. The August version of the Help Center article listed ten supported connectors: Asana, Atlassian, Canva, Datadog, Figma, Granola, Linear, Notion, Slack and Supabase.
The new version keeps that path intact and adds Claude as an alternative source of identity. The Help Center now separates the two clearly: the identity-provider route, for organizations with single sign-on enabled, is generally available, while the Claude-issued route, in which "Claude identifies the signed-in user to the connector using an issuer URL unique to your organization," is in beta and needs no identity provider at all.
........
Item | August 24, 2026 version | November 2026 version |
Identity sources | Identity provider only | Identity provider or Claude-issued |
Identity-provider route | Generally available | Generally available |
Claude-issued route | Not offered | Beta |
Supported identity providers | Okta | Okta (Claude-issued needs none) |
Connectors with managed auth | 10 | 15 |
Connectors with Claude-issued auth | None | 7 |
Plans | Team and Enterprise | Team and Enterprise |
........
The five connectors added to the managed-authorization list since August are Amplitude, Crossbeam, Lovable, Monday.com and Unblocked. The Claude-issued subset leans toward developer and analytics tools, with Atlassian and Notion as the main general-purpose workplace apps among the seven.
··········
CLAUDE-ISSUED AUTH VS IDENTITY-PROVIDER AUTH FOR TEAM AND ENTERPRISE ADMINS.
The two routes produce the same result for the employee, who finds the connector already connected the first time Claude needs it, without a sign-in page or consent screen. They differ in who vouches for the user and in what that guarantee covers, and Anthropic's documentation is explicit about the trade-off.
With the identity-provider route, the company's directory decides who gets access, and deprovisioning a user there removes connector access at the same time. With the Claude-issued route, the only check is membership in the Claude organization. The Help Center states that in this mode Claude "checks organization membership only," and does not verify single sign-on, multi-factor authentication or the connected service's own sign-in rules. Matching also happens by email: a member whose Claude email matches an account in the connected service is connected automatically, while a member whose email does not match sees the usual Connect prompt.
........
Aspect | Identity-provider route | Claude-issued route |
Status | Generally available | Beta |
Who vouches for the user | Company identity provider | Claude, via an issuer URL unique to the org |
Identity provider required | Yes (Okta today) | No |
What is checked | Directory groups, roles and IdP policy | Claude organization membership only |
Default role coverage | Roles the admin selects | All roles by default |
Revocation | Deprovision in the identity provider | Remove from Claude org and from the service |
Supported connectors | 15 | 7 |
........
The revocation rules carry the most practical weight. Anthropic warns that access already granted at a connected service lasts until it expires, even after the person is removed from Claude. Admins are told to remove departing users from each connected service before their email address can be reused, because the Claude-issued route links accounts by email. Organizations that sync users through SCIM should also note that Claude removes members only when the directory deletes them, not when it suspends or deactivates them.
··········
[[ADPLUS_300x250_1]]
HOW TO TURN ON CLAUDE PLUGIN AUTO-CONNECT IN THE ADMIN CONSOLE.
The setup flow starts in the same place for both routes. An admin opens Organization settings, then Connectors, selects a connector and clicks Set up next to Managed authorization on the Configuration tab. On the Connect step the admin chooses the identity source, then picks the roles that will receive the connector and the scopes, meaning the permissions Claude is allowed to request, before clicking Save & turn on. A custom role can be used to pilot a connector with a single team before extending it to everyone.
For the Claude-issued route, the Help Center describes four steps on the connected service's side and in Claude:
1. Copy the issuer URL that Claude shows for the organization and add it as a trusted issuer in the connected service's admin settings.
2. Optionally enter the tenant or workspace ID the service uses for the organization.
3. Click Test connection in Claude.
4. Click Enable and continue. All roles receive the connector by default; choosing Disable in the connector's Managed authorization settings turns it off.
Two behaviors are useful to know before a rollout. When browser sign-in and managed authorization are both enabled, Claude tries managed authorization first and falls back to individual sign-in if it fails. On a custom role's Connectors tab, admins can also set how members connect: individually, through managed authorization, or per connector. Members can still add personal connectors on top of the ones the organization provisions, and admins can require that a given connector connect only through managed authorization to keep personal accounts out of work tools.
The change arrives in the middle of a broader reorganization of Claude's interface. Anthropic is merging the separate Skills, Connectors and Plugins tabs into a single Plugins page, with general availability on November 9 for Free, Pro, Max, Ultra and Team plans and an Enterprise rollout on November 30. A plugin can bundle skills and connectors, which is why the announcement speaks of auto-connecting plugins while the admin console still configures each underlying connector. Readers comparing what each plan includes can find the full picture in our guide to Claude usage limits across Free, Pro, Max, Team and Enterprise, and recent Enterprise admin additions are covered in our report on Claude Enterprise smart reports and pooled group budgets.
··········
WHAT MCP SERVER BUILDERS NEED FOR CLAUDE ENTERPRISE-MANAGED AUTH.
The developer side of the feature sits on an open extension to the Model Context Protocol, `io.modelcontextprotocol/enterprise-managed-authorization`. In the extension's flow, the client obtains a signed token called an Identity Assertion JWT Authorization Grant (ID-JAG) and exchanges it at the MCP server's authorization server for an access token, without sending the user through the server's own authorization page. Anthropic's connector documentation describes the exchange as a single back-channel request based on the JWT bearer grant defined in RFC 7523.
The documentation sets out three requirements for the authorization server. It must accept the JWT bearer grant at its token endpoint and advertise it in its metadata, because Claude reads that metadata to decide whether to offer the feature to customers. The example in Anthropic's docs shows the entry Claude looks for:
{
"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"
]
}It must keep an explicit allowlist of trusted issuer URLs for each customer tenant and reject an assertion whose issuer is not on that list with `invalid_grant`, even when the signature is valid. And it must already recognize Claude's client, registered either with Anthropic-held client credentials or a Client ID Metadata Document, because Dynamic Client Registration is not supported in this flow: the assertion carries a fixed `client_id` that a client created on the fly would never match.
Claude then sends a form-encoded request to the token endpoint. Anthropic's documentation gives this example:
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.comThe `resource` parameter, which binds the token to the MCP server's URL, is included only when the issuer can forward it, so servers are told to accept requests with or without it. Access token lifetime is left to the server operator. The feature also works with lazy authentication: when a server answers a protected tool call with `401 Unauthorized`, Claude runs the silent exchange instead of showing the Connect card, provided the organization has managed authorization configured for that connector. Servers that are entirely authless never return a 401 and therefore cannot use the flow.
In practice the Claude-issued route asks one extra thing of a service: an admin setting where a customer can paste Claude's issuer URL as a trusted issuer, ideally with a field for a tenant or workspace ID. Anthropic invites developers who add support to contact its MCP review team at mcp-review@anthropic.com so their directory listing can be marked as supporting Enterprise Managed Auth. Developers who want background on how Claude's connector catalog started can read our coverage of the Claude connectors directory launch.
··········
CLAUDE-ISSUED PLUGIN SIGN-IN: CONFIRMED FACTS AND OPEN QUESTIONS.
The confirmed part is clear. Team and Enterprise organizations can now auto-connect a limited set of seven connectors without an identity provider, by letting Claude act as the issuer that vouches for their members; the identity-provider route remains generally available and still supports Okta only; and the overall list of connectors with managed authorization has grown from ten in August to fifteen. The Help Center does not mention Pro, Max or Ultra plans for any form of managed authorization, so individual subscribers keep connecting each service themselves.
Several points remain undocumented. Anthropic has not published a timeline for the Claude-issued route to leave beta, has not named the next identity providers after Okta, and has not said which of the other eight managed-auth connectors will add Claude-issued support. The connector-developer documentation describes the identity-provider exchange in detail but gives far less on the Claude-issued assertion itself, such as its claims and lifetime.
The security trade-off is the deciding factor for admins. The Claude-issued route removes the dependency on Okta at the price of a weaker check: membership in the Claude organization and a matching email, with no single sign-on or multi-factor verification behind it, and with already issued service tokens surviving a user's removal until they expire. For companies without a supported identity provider that already manage offboarding carefully in tools such as Atlassian, Notion or Datadog, that trade can be acceptable for a pilot. Companies that rely on directory policy and conditional access to control who reaches production data will find the identity-provider route the closer match to their existing controls.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
