Skip to main content
Authentication is the most common source of partner questions. Claude’s auth support differs in a few places from the generic MCP specification, so read this page even if you’re already familiar with MCP auth.

​
Supported authentication types

Claude supports the following authentication types for remote MCP servers. The same infrastructure backs Claude.ai, Claude Desktop, Claude mobile, Claude Code, and Cowork.
TypeDescriptionAvailability
oauth_dcrOAuth 2.0 with Dynamic Client Registration (RFC 7591)Supported out of the box
oauth_cimdOAuth 2.0 with Client ID Metadata DocumentSupported out of the box
oauth_anthropic_credsOAuth 2.0 with Anthropic-held client credentialsContact [email protected]
custom_connectionCustom URL or credentials supplied at connection time (for example, Snowflake-style)Contact [email protected]
noneNo authentication (authless server)Supported. An optional partial-auth mode is experimental.
User-pasted bearer tokens (static_bearer) are not yet supported.

​
Anthropic-held client credentials

A pure machine-to-machine client_credentials grant—where a server-to-server token is issued with no user in the loop—is not supported. Every connection requires user consent. oauth_anthropic_creds is the consent-gated alternative. The flow works like this:
  1. You create an OAuth client_id and client_secret in your own authorization server and send them to Anthropic.
  2. Anthropic stores those credentials securely and associates them with your directory entry.
  3. When a user connects your server, they go through a standard OAuth consent screen.
  4. After consent, Anthropic uses the stored client credentials to complete the token exchange on the user’s behalf.
This gives you a stable, registered OAuth client without requiring DCR or CIMD on your end, while keeping the user-consent step. Anthropic stores your credentials securely and uses them only for token exchange on behalf of consenting users; they are shared across Claude.ai, Desktop, mobile, Cowork, and Claude Code (Claude Managed Agents uses a separate credential set). To use this flow, email [email protected] with your client_id and secret.

​
DCR and CIMD details

If your authorization server does not expose a registration_endpoint (i.e., does not support DCR), you have several options:
  • Expose a registration_endpoint
  • Support CIMD instead — also include "none" in token_endpoint_auth_methods_supported, since a URL-identified client is public by definition
  • Switch to oauth_anthropic_creds
For 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.

​
Callback URLs

For the hosted Claude surfaces (Claude.ai web, Desktop, mobile, and Cowork), register the following redirect URI: 
https://claude.ai/api/mcp/auth_callback
Claude Code is a native client and uses an RFC 8252 loopback redirect on an ephemeral port — for example: 
http://localhost:3118/callback
The port varies per session. Claude Code declares http://localhost/callback and http://127.0.0.1/callback in its Client ID Metadata Document, so your authorization server must accept both with the port component ignored. RFC 8252 section 7.3 requires this for the IP-literal form (127.0.0.1); apply the same port-agnostic match to localhost so Claude Code works, even though RFC 8252 section 8.3 discourages localhost. See lazy authentication for implementation details.

​
Token refresh

Claude refreshes tokens reactively on a 401 response, with a proactive refresh up to five minutes before the stored expiry. To avoid refresh failures:
  • Return RFC 6749-compliant error codes (invalid_grant, not invalid_request or a custom code) when a refresh token is no longer valid
  • Honor refresh-token rotation correctly if you rotate tokens

​
Enterprise authentication

Claude uses a single shared OAuth application per connector. Tenant-level isolation and enterprise-specific OAuth clients are not supported. Enterprise customers connect to the same OAuth app as everyone else; access is scoped by the user’s own permissions on your service.

​
Custom connectors

When a user adds a custom connector by URL, the OAuth Client Secret field is optional. Supply it only if your authorization server requires confidential-client authentication.

​
Network reference

Anthropic’s outbound traffic to your server originates from 160.79.104.0/21. See the IP address reference if you need to allowlist Anthropic for conditional access or firewall rules.