Enterprise Managed Auth for connectors changedconnectors/building/enterprise-managed-auth
Nearest release: v2.1.318, published 17 hours before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 4 Nov 2026 15:50 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 4 Nov 2026 16:07 UTC.
Upstream edited
Recorded here
Lines+12added
Lines−2removed
From line
32
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits15to this page, all time
The whole hunk
from line 32, old and new numbered
/
from line 32
3232Before adding Enterprise Managed Auth, make sure the following are already in place:
3333
3434* Your MCP server implements [MCP authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization), including Protected Resource Metadata (PRM) discovery. See the [authentication guide](https://claude.com/docs/connectors/building/authentication.md) for Claude-specific requirements
35* Your authorization server registers Claude using either [Anthropic-held client credentials](https://claude.com/docs/connectors/building/authentication.md#anthropic-held-client-credentials) or a [Client ID Metadata Document](https://claude.com/docs/connectors/building/authentication.md#dcr-and-cimd-details)
35* Your authorization server registers Claude using either a client that Anthropic set up for your server's URL, as [Which credentials Claude uses when several are set](https://claude.com/docs/connectors/building/authentication.md#which-credentials-claude-uses-when-several-are-set) describes, or a [Client ID Metadata Document](https://claude.com/docs/connectors/building/authentication.md#dcr-and-cimd-details). Enterprise Managed Auth sign-ins don't use a client ID and secret that you entered in the developer portal. If that is how Claude is registered with you, email `[email protected]` with your listing's name and its exact server URLs before you ask to have your listing marked as supporting Enterprise Managed Auth, and don't put the secret in the email
3636
3737Enterprise Managed Auth works with [lazy authentication](https://claude.com/docs/connectors/building/lazy-authentication.md). When your MCP server answers a tool call with `401 Unauthorized` and the user's organization has Enterprise Managed Auth configured for your connector, Claude runs the exchange and retries the call instead of showing the **Connect** card.
3838
from line 95
9595&resource=https://mcp.example.com
9696```
9797
98Client authentication is left out of this example. The `client_id` is the value Claude is registered under at your authorization server, which for a Client ID Metadata Document is the document's URL. If that client has a secret or key, require it on this request. Answer at the `token_endpoint` URL itself, because Claude doesn't follow redirects on this request.
98Client authentication is left out of this example. Answer at the `token_endpoint` URL itself, because Claude doesn't follow redirects on this request. The `client_id` is the value Claude is registered under at your authorization server, which for a Client ID Metadata Document is the document's URL. If that client has a secret or key, require it on this request:
99
100* **Client secret**: Claude sends the secret in the request body, so accept `client_secret_post` for this client
101* **Signed client assertion**: if Claude is registered with you through its Client ID Metadata Document and your authorization server metadata lists `private_key_jwt` in `token_endpoint_auth_methods_supported`, Claude can send this request as a second client, `https://claude.ai/oauth/mcp-oauth-client-metadata/confidential_client`, with a signed client assertion. Accept that `client_id` as well as the public document's URL, and verify the client assertion with the keys at the `jwks_uri` in the `confidential_client` document
102
103The **Client** check in [Validate the identity assertion](#validate-the-identity-assertion) compares the assertion's `client_id` claim with this request's `client_id`:
104
105* **Claude-issued**: the claim names the client that sends this request
106* **Identity provider-issued**: the claim is the client ID that the customer's administrator registered for your connector in their identity provider. Claude's managed authorization setup gives the identity provider's setup the client ID that Claude presents on this request, so the two values should match when the administrator registers your connector through it. An administrator who registers your connector another way must enter the client ID that Claude presents on this request, so name it in your setup documentation
107
108Adding or removing `private_key_jwt` in `token_endpoint_auth_methods_supported` changes which client Claude presents through its metadata document. After customers are set up, that change can make their identity provider-issued sign-ins fail the **Client** check until each administrator runs Claude's managed authorization setup again or enters the new client ID in their identity provider. Tell administrators before you make it.
99109
100110A Claude-issued request always carries the `resource` parameter ([Resource Indicators, RFC 8707](https://www.rfc-editor.org/rfc/rfc8707)), set to the `resource` in your Protected Resource Metadata when that is your MCP server's URL or a parent of it, and otherwise to your MCP server's URL. An identity provider-issued request carries it whenever the customer's identity provider supports forwarding it. Accept the request whether or not `resource` is present, and use it for audience binding when it is.
101111
No line in this hunk matches that.