How OAuth Works for a Remote MCP Server

Description and use

Clients can securely authenticate to a remote MCP server using OAuth 2.1 without secrets, via dynamic registration or client‑ID metadata documents.

Problem

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

Outcome

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.

Workflow

• 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.

Evidence

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.

Source

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

Source

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

Source

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

Source