How OAuth Works for a Remote MCP Server

说明与用途

客户端可以使用 OAuth 2.1 在不存储秘密的情况下安全地对远程 MCP 服务器进行身份验证，使用动态注册或客户端 ID 元数据文档。

问题

Integrating a remote MCP server into a client without exposing secrets or requiring pre‑registered credentials.

结果

Clients can now authenticate to any MCP server without pre‑configured secrets, using dynamic registration or client‑ID metadata documents, and access protected resources securely.

工作流

• 1. Client sends unauthenticated request to MCP endpoint and receives 401 with WWW‑Authenticate header.
• 2. Client retrieves protected‑resource metadata from the well‑known URL specified in the header.
• 3. Client fetches authorization‑server metadata from its well‑known URL.
• 4. Client obtains a client ID either by dynamic client registration or by using a client‑ID metadata document.
• 5. Client initiates OAuth authorization code flow with PKCE, using the obtained client ID and redirect URI.
• 6. User authenticates, authorization server issues code, client exchanges code for access token.
• 7. Client uses access token in Authorization header to call protected MCP methods.

证据

When you add a remote MCP server to Claude, Cursor or Claude Code, a browser window opens, you log in, and the client is connected. No API key, no config file with a secret in it.

来源

The WWW‑Authenticate header is the starting point for everything else. It tells the client three things: Bearer, resource_metadata, scope.

来源

The fields a client reads here: authorization_endpoint and token_endpoint: where to send the user, and where to exchange the code.

来源

With Dynamic Client Registration (RFC 7591), the client registers itself at runtime.

来源