OAuth for MCP (dynamic client registration)

What it is

The MCP specification makes authorisation optional, but defines how to do it for HTTP transports. The MCP server acts as an OAuth 2.1 resource server, the MCP client as an OAuth client, and an authorisation server issues the tokens. It builds on existing standards: OAuth 2.1, Authorization Server Metadata (RFC 8414), Protected Resource Metadata (RFC 9728), Dynamic Client Registration (RFC 7591), Resource Indicators (RFC 8707) and PKCE (RFC 7636).

Why it matters

A client and a server usually have no prior relationship. Someone adds a URL, and the client has to find out where to sign in and obtain a client ID without a developer registering an app by hand. Done well, the person clicks through one consent screen and never pastes a secret anywhere.

How it works

1. Discovery. The client calls the server without a token and gets a 401 whose WWW-Authenticate header points to the protected resource metadata, which names the authorisation server.
2. Registration. The client gets a client ID in one of three ways: a Client ID Metadata Document (the client ID is an HTTPS URL that hosts its metadata), pre-registration, or Dynamic Client Registration, where the client posts its metadata to a registration endpoint and receives an ID. In revision 2025-11-25, metadata documents are the recommended route and dynamic registration is optional; revision 2026-07-28 marks dynamic registration deprecated, kept for backward compatibility.
3. Authorisation. The client opens the browser with a PKCE challenge (S256 required where possible) and a resource parameter naming the server. The person signs in and consents.
4. Token. The client exchanges the code and verifier for an access token bound to that server, and sends it in the Authorization header on every request, never in the URL.

The server must accept only tokens issued for itself and must never pass them through to another API.

Example

Running claude mcp add --transport http actionlake https://connect.actionlake.com/mcp and then making the first call opens a consent page. The person names the client, approves, and Claude Code receives a token for that endpoint.

Common pitfalls

• Advertising what you do not support. A client that reads a capability from metadata and cannot complete it may stop rather than fall back.
• Token passthrough. Forwarding the client's token to a vendor API is forbidden by the specification and breaks audit.
• Confused deputy. A proxy with a static client ID at a third-party authorisation server must get consent per dynamically registered client.
• Loose redirect checks. Redirect URIs must match the registration exactly.

How actionlake handles it

The actionlake API runs its own OAuth 2.1 authorisation server for MCP clients. It publishes RFC 8414 and RFC 9728 metadata, offers RFC 7591 dynamic client registration, requires PKCE with S256, matches redirect URIs exactly, makes codes single-use, rotates refresh tokens on every use (killing the chain on reuse) and supports revocation (RFC 7009). Client ID Metadata Documents are accepted from an allow-listed set of client hosts and are not advertised in the server's metadata, so a client should expect dynamic registration. An access token resolves to the actionlake key the person consented for, so the same permissions, caps and approvals apply. Connecting a vendor that uses OAuth, such as an accounting system, is separate: you register your own app with the vendor, an admin signs in once, and the tokens are stored as a connection. Vendors that use API keys an agent can connect itself. The vendor token goes to the credential vault, never to the agent.