Claude now connects your apps on its own at login: how it works, who accepts it and what to check before you switch it on

What you get from this article

• The official name is Enterprise-managed auth. The identity provider mode is already available; the mode where Claude itself signs, Claude-issued, has been in beta since 3 November 2026.
• It covers Team and Enterprise plans. On Free and Pro, each person still connects apps with their own sign-in.
• Seven apps accept Claude as the issuer: Amplitude, Atlassian, Datadog, Figma, Linear, Notion and Supabase. Eight more work only through Okta.
• Setup needs a Claude admin and an admin of the app, because the app decides whom to trust.
• Claude only checks that the person is a current member of the organization. SSO, two-step verification and the app's own sign-in rules are left out.
• People are matched by email. An address reused before old accounts are cleaned up can hand a former employee's account to the new hire.
• For a product to accept Claude as the issuer, its authorization server needs the JWT bearer grant and nine checks, and dynamic client registration is out.

What Anthropic released on 3 November

On the afternoon of 3 November 2026, at 18:09 UTC, Anthropic's developer account on X announced that users can now auto-connect plugins when they log in to Claude, with MCP servers that accept Claude as a trusted issuer. The post ends with a request to anyone building plugins: add support, so users get started faster and stay connected without re-authorizing. In under four hours it passed 297,000 views.

The technical name, in the support article published the same day, is Enterprise-managed auth, with two identity sources. In the first, the company's identity provider, today only Okta, signs the employee into the app, and that one is already available to Team and Enterprise customers. In the second, the news of the day, Claude itself does the signing, with no identity provider and no SSO. That is Claude-issued auth, in beta.

The post says plugins and the documentation says connectors, and the difference matters little here. A plugin is the package you install in Claude, and it can bring connectors with it. A connector is the link to an outside app, made through an MCP server. The connector is what now connects on its own. If MCP is still just an acronym to you, our piece on what MCP is explains the standard from the start.

Anyone who uses Claude with lots of apps knows the problem this change goes after. In the Claude account ROO3 uses for work, on the 3rd itself, Claude listed 64 MCP servers from installed plugins waiting for authorization, each with its own sign-in. Notion, Linear, Figma, Amplitude and Atlassian were among them, five of the seven beta apps. The new feature does not fix that case by itself, because it applies to Team or Enterprise organizations and needs the admin of each app on the other side. It does show the size of the queue it wants to clear.

The sign-in every employee did in every app becomes a setting the admin configures once per app.

How it works, without the jargon

Picture a front desk that knows every employee. Instead of each company system checking its own badge, it accepts a note signed by the front desk saying this is Ana from finance and she works here today. Claude plays the front desk. The app only has to recognize the signature.

Each Claude organization gets its own issuer URL, at identity.anthropic.com/issuers/ followed by an identifier that is not the organization's ID. The app's admin registers that URL as the trusted issuer for the company's workspace. When an employee uses the app through Claude, Claude signs a short credential, which the standard calls an ID-JAG, carrying the person's email, the app it is meant for and a lifetime of under a minute. The app's authorization server checks the signature against the public keys published at that URL and returns an access token, the same kind of token a normal sign-in would produce.

When the token expires, Claude signs a fresh credential and exchanges it again, with nobody clicking anything. The developer documentation says plainly that a one-hour token does not make the employee sign in again every hour. And if the app answers mid-conversation that it does not recognize the person, with a 401 error, Claude runs the exchange and retries the request before showing the connect button.

None of this was invented in November. The flow follows the MCP enterprise-managed authorization extension, published as a specification on 28 July 2026, and the credential follows a draft from the IETF OAuth working group. What changes now is who can sign. Until now, only a corporate identity provider could, and when Supabase launched the feature in August, Okta was the only one that supported it. Supabase says Claude is the first MCP client to implement the extension.

Each app used to check its own badge. Now they all accept Claude's note, and whoever has access to Claude takes the rest along.

Who accepts it and who is left out

Seven apps accept Claude as the issuer in the beta: Amplitude, Atlassian, Datadog, Figma, Linear, Notion and Supabase. Eight more support enterprise-managed auth only through the identity provider: Asana, Canva, Crossbeam, Granola, Lovable, Monday.com, Slack and Unblocked. Some reports on the day said 14 apps; the official list has 15.

For a small company, the gap between the two groups is wide. The identity provider mode requires SSO in Claude and in the app, and Okta is the only provider Claude accepts today. According to the extension page on the MCP site, Okta includes issuing these credentials in its SSO plan with a cap of 250 per user, per app, per month, and higher volume requires another Okta product, Okta for AI Agents. Without Okta, the only option was signing in one person at a time.

Each app adds its own conditions. Linear requires a Business or Enterprise plan on its side and the same email in both systems. Supabase requires a Team or Enterprise plan, SSO set up, and every member to have signed in through SSO at least once. It also warns that switching the issuer to Claude turns off the previous one: it trusts a single issuer per SSO provider, and other AI tools that relied on Okta lose access until it is restored.

The developer documentation adds one more restriction: a Claude organization that signs in through Okta does not get the Claude-issued option. Each connector uses one identity source at a time, and companies already on Okta stay on it.

Apps with automatic sign-in in Claude on 3 November 2026

	Claude signs beta, no Okta
Amplitude product analytics	yes
Atlassian Jira and Confluence	yes
Datadog monitoring	yes
Figma design	yes
Linear project management	yes
Notion docs and wiki	yes
Supabase database	yes
Asana task management	no
Canva design	no
Crossbeam partnerships	no
Granola meeting notes	no
Lovable app building	no
Monday.com work management	no
Slack messaging	no
Unblocked code search	no

What the admin sets up, on both sides

Setup happens once per app and takes two people, or one person with two logins: a Claude admin and an admin of the app. Without the second, nothing happens, because the app decides whom to trust. If you do not run the app, Claude has a button that sends the URL and the setup guide to whoever does.

Anthropic recommends starting small. Organization roles let you turn the connector on for one group only, such as a pilot with the product team, and it suggests asking two or three users to confirm the connection and run a real request before announcing it company-wide. On the same screen, the admin picks which permissions Claude can request, and can narrow them for each role.

Individual sign-in does not go away. Both modes can be on at once, and then Claude tries the automatic one first and falls back to the normal sign-in if it fails, so nobody is locked out while a setup problem gets fixed. Anyone with a different email in the app sees the usual connect button. And the admin can require a connector to connect only through managed authorization, which keeps personal accounts out of work tools.

The path, according to Anthropic's support article and Linear's guide, has five steps:

• In Claude, open Organization settings, then Connectors, pick the app and click Set up next to Managed authorization.
• Under Identity source, choose Claude-issued and copy the Issuer URL.
• In the app's admin console, register that URL as the workspace's trusted issuer. In Linear, it lives under Workspace settings, Security.
• If the app shows a workspace identifier (Tenant ID), paste it into the matching field in Claude.
• Run the connection test in Claude, enable it and choose which roles get the connector and which permissions it can request.

The two gaps that stay with your company

The first is spelled out in the support article: Claude only checks that the person is a current member of the organization. It does not check whether they signed in through SSO, used two-step verification, or met the app's own sign-in rules. With automatic sign-in on, anyone who gets into an employee's Claude account, through their email or the Google account linked to it, gets Notion, Linear and everything else on the list as well. Anthropic recommends enforcing SSO for the organization even though this setup does not need it, and the recommendation stops being optional the day the first connector goes live.

The second is email. The person in Claude and the account in the app are matched by address, and the support article states the risk bluntly. When someone leaves, Claude stops signing for them, but access already granted in the app lasts until it expires. And if that email is reused before the old account is removed from the app, the new person can be signed in to the old account. In small companies, reused addresses are routine: the salesperson leaves and the replacement inherits sales@ with the whole inbox.

Directory sync does not close everything. Teams that create and remove people automatically through SCIM need to know that Claude removes a member when the directory deletes them, but not when it only suspends them or marks them inactive. And Supabase points out that, with Claude as the issuer, disabling someone in the identity provider no longer cuts their access, because neither Claude nor Supabase asks the provider whether the person is still active. The fix in both cases is to remove the person from the Claude organization and from each connected app.

Then there is personal data. At the company's instruction, Anthropic sends the app each member's email and a unique identifier. That is employee data going to a third party, and it belongs in the record of processing operations that article 37 of Brazil's LGPD requires from the controller, the same record article 30 of the GDPR asks for. Our piece on LGPD and AI helps organize that map. Before turning on the first connector, check:

• SSO enforced for Claude sign-in or, at the very least, two-step verification on the email and Google account that give access to it.
• The same email for each person in Claude and in the app, with no shared inbox in between.
• When someone leaves, removal from Claude and from every connected app on the same day.
• No departed employee's email reused before the old account is gone from every app.
• A pilot role first, widened only after two or three real tests.

If you build a product and want to be on that list

The post's closing message is for developers: add support. The documentation published alongside it shows that the work sits in the app's authorization server. The MCP server itself receives the same kind of token it would get after the interactive sign-in, and does not change.

The prerequisites rule many out right away. The MCP server must implement MCP authorization with protected resource metadata discovery, and Claude must be registered with the authorization server through Anthropic-held client credentials or a Client ID Metadata Document. Dynamic client registration, the shortcut many servers use, does not work in this mode. The authorization server also has to accept the JWT bearer grant from RFC 7523 at its token endpoint, advertise it in its metadata, and answer at the token URL itself, because Claude does not follow redirects on that request.

The most delicate point is in a highlighted warning: an issuer URL is not a secret. Anyone can register another customer's issuer, or an identity provider of their own, in a workspace they control, and whoever runs a provider can put any email they like in the credential. So the app may sign someone in by email only if it has verified that address, or if it sits on a domain the customer has verified. Skip that rule and you hand one customer's account to another.

To be marked as supported in Claude's connector directory, the developer tests in a Team organization that does not sign in through Okta, passes the eight cases on the launch list, six of them refusals, publishes a help page for the customer's admin and writes to mcp-review@anthropic.com. During development, Okta's test environment at xaa.dev exercises the server without a Claude organization.

Before any of that, every token request has to pass nine checks, in this order, and any failure returns invalid_grant. The documentation says to use the validation built into your authorization product instead of writing your own:

• Issuer: iss equal, as an exact string, to the issuer registered for that workspace. Matching only the start of the URL admits other customers' users.
• Keys: fetched from the issuer's own discovery document, never from a key or URL carried in the credential's header.
• Signature: ES256 or RS256 only. Claude signs with ES256.
• Type: the typ header equal to oauth-id-jag+jwt.
• Audience: aud equal to the issuer the authorization server publishes.
• Client: the credential's client_id equal to the request's.
• Subject: sub present. With Claude's credential, the person is found by email, not by sub.
• Time: validity checked, with at most 60 seconds of clock skew.
• Replay: each jti accepted once. If the server cannot check, it refuses.

When it makes sense to switch it on, and where ROO3 comes in

For a company already paying for Claude Team and using two or more of the seven apps, the gain shows up on day one and the risk is manageable: turn it on for a pilot role, check the emails, enforce SSO and write down the offboarding procedure before widening it. For companies on Okta, nothing changes. The identity provider mode stays, and it is the one that honors the access rules IT has already set up.

For companies that use none of these apps, the release still signals where things are going. Connecting AI to company systems moves out of each employee's hands and into the admin's, with roles, permissions and revocation. That is how an agent should work with real data, as we explain in our piece on agentic AI, and it is the part that usually gets left for later.

At ROO3, we put AI to work inside the company's routine, in the CRM, on WhatsApp and in spreadsheets, with the least permission that gets the job done and with departing people losing access the same day, and we train the team to use it. If your company wants AI in day-to-day operations without opening a door nobody watches, or you have your own product and want it to talk to your customers' AI, talk to us before you turn on the first connector.

Frequently asked questions

What is Claude-issued auth?

It is the mode in which Claude itself signs an employee into a connected app, under an issuer URL unique to the organization. The app registers that URL as a trusted issuer and accepts the signature in place of the sign-in and consent screens. It has been in beta since 3 November 2026.

Does it work on Claude Free or Pro?

No. Enterprise-managed auth is for Team and Enterprise plans. On Free and Pro, each person still connects apps with their own sign-in.

Do I need Okta or SSO?

Not for the mode where Claude signs. It needs no identity provider or SSO, although Anthropic recommends enforcing SSO for the organization. For the identity provider mode, yes, and today Okta is the only provider Claude accepts.

Which apps accept Claude as the issuer?

In the beta, seven: Amplitude, Atlassian, Datadog, Figma, Linear, Notion and Supabase. Eight more, Asana, Canva, Crossbeam, Granola, Lovable, Monday.com, Slack and Unblocked, support enterprise-managed auth only through the identity provider. Each app has its own plan conditions.

What happens when an employee leaves?

Claude stops signing for them as soon as they are removed from the organization, but access already granted in each app lasts until it expires. Remove the person from each app too, and do not reuse the email before that, because the app recognizes the person by address.

Can my product accept Claude as the issuer?

Yes, if your MCP server already has OAuth authorization with metadata discovery, registers Claude without dynamic client registration, accepts the JWT bearer grant and runs the nine checks in the documentation, including signing people in only by verified email. After testing, the developer asks Anthropic, at mcp-review@anthropic.com, to mark the listing in the connector directory.

Sources

• ClaudeDevs on X, automatic plugin sign-in announcement (3 Nov 2026)
• Anthropic, Auto-connect your organization's apps to Claude (3 Nov 2026)
• Anthropic, Enterprise Managed Auth for connectors (developer documentation)
• Model Context Protocol, Enterprise-Managed Authorization extension
• IETF, Identity Assertion JWT Authorization Grant draft
• Supabase, Claude can now issue the identity assertion (3 Nov 2026)
• Supabase, Enterprise-managed authentication for the Supabase MCP Server
• Linear, MCP server: Claude auto-connect
• Law 13,709/2018 (LGPD), article 37 (in Portuguese)

Rodrigo Fávaro

Founder of ROO3, a marketing and technology agency in São José do Rio Preto, Brazil. Builds AI products running in production (Tobia, gerar.app, Pense Mercado) and maintains the AI Benchmark, a public ranking of AI models. See ROO3 AI consulting.

X @rodmf LinkedIn rodrigofavaro