Authentication for connectors changedconnectors/building/authentication
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+5added
Lines−4removed
From line
14
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits13to this page, all time
The whole hunk
from line 14, old and new numbered
/
from line 14
1414
1515* A `401` is required to start sign-in, and Claude ignores a `WWW-Authenticate` header on a `200` response, as [Serve discovery metadata](#serve-discovery-metadata) describes
1616* Claude uses only the first entry in your metadata's `authorization_servers` list, as [Serve discovery metadata](#serve-discovery-metadata) describes
17* Claude uses a Client ID Metadata Document only when your authorization server metadata advertises both values in [DCR and CIMD details](#dcr-and-cimd-details), and otherwise falls back to DCR
17* Claude normally uses a Client ID Metadata Document only when your authorization server metadata advertises both values in [DCR and CIMD details](#dcr-and-cimd-details), and otherwise falls back to DCR
1818* Claude Code's loopback redirect needs a port-agnostic match for `localhost` as well as `127.0.0.1`, as [Callback URLs](#callback-urls) describes
1919* Claude gives your discovery, registration, and token endpoints 10 seconds to respond and refresh requests 30 seconds, as [Endpoint latency](#endpoint-latency) describes
2020* A machine-to-machine `client_credentials` grant isn't supported, and [Anthropic-held client credentials](#anthropic-held-client-credentials) are the consent-gated alternative
from line 85
8585If your authorization server doesn't support DCR, meaning it exposes no `registration_endpoint`, you have these options:
8686
8787* Expose a `registration_endpoint`
88* Support CIMD instead. Claude selects CIMD only when your authorization server metadata advertises both `"client_id_metadata_document_supported": true` and `"none"` in `token_endpoint_auth_methods_supported`. The second is required because Claude's CIMD client authenticates as a public client at your token endpoint. If either is missing, Claude falls back to DCR. See [lazy authentication](https://claude.com/docs/connectors/building/lazy-authentication.md#identify-claude-with-a-client-id-metadata-document) for a worked CIMD example
88* Support CIMD instead. Claude normally selects CIMD only when your authorization server metadata advertises both `"client_id_metadata_document_supported": true` and `"none"` in `token_endpoint_auth_methods_supported`, and otherwise falls back to DCR. The second value is required because Claude's CIMD client authenticates as a public client at your token endpoint in that case. If your metadata lists `private_key_jwt`, Claude can instead present a second metadata document, whose URL ends in `/confidential_client`, and authenticate with a signed client assertion. On [Enterprise Managed Auth](https://claude.com/docs/connectors/building/enterprise-managed-auth.md) exchanges it can do this even when `"none"` isn't listed, and on other sign-ins only for some servers. See [lazy authentication](https://claude.com/docs/connectors/building/lazy-authentication.md#identify-claude-with-a-client-id-metadata-document) for a worked CIMD example
8989* Switch to `oauth_anthropic_creds`, if your listing doesn't use a URL pattern
9090
91If your server URL varies per customer and DCR isn't available, CIMD is the recommended path. Every customer's authorization server must advertise both CIMD values. Otherwise Claude falls back to DCR for that customer, which needs a `registration_endpoint`.
91If your server URL varies per customer and DCR isn't available, CIMD is the recommended path. Every customer's authorization server must advertise both CIMD values. Otherwise Claude normally falls back to DCR for that customer, which needs a `registration_endpoint`.
9292
9393For servers expecting high traffic from the directory, prefer CIMD or `oauth_anthropic_creds` over DCR. DCR causes Claude to register a new client on every fresh connection, which can result in very large numbers of registered clients on your authorization server. CIMD and Anthropic-held credentials avoid the registration call entirely.
9494
from line 134
134134* **Some connections, such as older ones**: these don't use the client you entered. They use the organization's or Anthropic's client if either exists, and otherwise your server's own [DCR or CIMD](#dcr-and-cimd-details) registration. If there's no such client and your server supports neither, sign-in fails for those connections
135135* **A client Anthropic already holds**: if Anthropic holds a client for any of your listing's URLs, you can't save your client secret or request header values on a published listing. You can save them once Anthropic removes its client or checks your listing again. On a listing that isn't published yet, you can save them, but the listing can't go live until Anthropic checks it. In either case, email `[email protected]` with your listing's name and its exact server URLs, and don't put the secret in the email
136136* **Custom connectors**: a custom connector that someone adds with your server's URL never uses the client secret you entered in the portal
137* **Enterprise Managed Auth sign-ins**: these don't use the client you entered in the developer portal. For how to register Claude for those sign-ins, see [Enterprise Managed Auth prerequisites](https://claude.com/docs/connectors/building/enterprise-managed-auth.md#prerequisites)
137138
138139For each request header on your listing, select the **Anthropic holds one shared value** checkbox in the developer portal to enter one value yourself that every organization uses. Leave it unchecked so each person who adds your connector enters their own value. You can't select the checkbox on a listing with a [URL pattern](#servers-with-per-customer-urls). Header values come only from you or from the people who add your connector, never from Anthropic.
139140
from line 226
225226Claude refreshes tokens reactively on a `401` response, and proactively up to five minutes before the stored expiry. To avoid refresh failures:
226227
227228* Return RFC 6749-compliant error codes when a refresh token is no longer valid: `invalid_grant`, not `invalid_request` or a custom code
228* Rotate refresh tokens for public-client connections. DCR and CIMD register Claude as a public client, and the [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-theft) adopts OAuth 2.1's requirement to rotate or sender-constrain refresh tokens for public clients. If you rotate, return the new refresh token in the same response that invalidates the old one
229* Rotate refresh tokens for public-client connections. DCR registers Claude as a public client, and CIMD normally does too. The [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-theft) adopts OAuth 2.1's requirement to rotate or sender-constrain refresh tokens for public clients. If you rotate, return the new refresh token in the same response that invalidates the old one
229230
230231Your `/token` endpoint must accept `Content-Type: application/x-www-form-urlencoded` per [RFC 6749 section 4.1.3](https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3). Claude sends both the initial token exchange and refresh requests with this content type. Some web frameworks default to JSON-only body parsing, so if your endpoint returns `415 Unsupported Media Type`, register a form-urlencoded body parser. Dynamic client registration at `/register` uses `application/json` per [RFC 7591 section 3.1](https://www.rfc-editor.org/rfc/rfc7591#section-3.1), so don't assume the same parser works for both.
231232
No line in this hunk matches that.