How OAuth Works for a Remote MCP Server

Описание и применение

Клиенты могут безопасно аутентифицироваться в удалённом сервере MCP, используя OAuth 2.1 без секретов, динамическую регистрацию или документы метаданных клиента.

Задача

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.

Источник