Securing MCP with OAuth 2.1: Discovery, Authorization and Access

Why OAuth 2.1 for MCP

OAuth 2.1 is the officially mandated authorization standard in the Model Context Protocol specification. It gives a modern, standardized approach for granting clients controlled access to protected MCP servers. The spec requires authorization servers to implement OAuth 2.1 with appropriate security measures for both confidential and public clients.

Discovery phase

When an MCP client attempts to access a protected resource, the MCP server returns a 401 Unauthorized response and includes a WWW-Authenticate header that points to the server’s authorization endpoint. The client uses the metadata exposed by the authorization server to discover supported features, endpoints, and requirements. This initial discovery step tells the client whether dynamic client registration is available, which OAuth flows are supported, and what security controls are enforced.

Registration and authorization

After discovery, the client proceeds to register and request authorization.

Dynamic Client Registration

If the authorization server supports dynamic client registration, clients can register automatically by sending basic details such as client name, client type, redirect URIs, and requested scopes. The server responds with client credentials, commonly a client_id and client_secret, streamlining onboarding for many automated or large scale deployments.

Choosing the OAuth flow

• Authorization Code flow: used when acting on behalf of a human user. The user is prompted to give consent, and after approval the authorization server issues an authorization code which the client exchanges for an access token. PKCE must be used to protect the code exchange.
• Client Credentials flow: used for machine to machine communication where no user is present. The client authenticates directly with the authorization server and receives an access token scoped for service level operations.

Access phase

Once the client holds an access token, it attaches that token to requests sent to the MCP server. The MCP server validates the token, ensures the token grants the requested scopes, and then processes the request. All interactions should be logged for auditing and compliance so that authorization decisions and access events are traceable.

Key security enhancements in MCP OAuth 2.1

MCP augments OAuth 2.1 with several mandatory and recommended controls:

• Mandatory PKCE

  All MCP clients must use PKCE. PKCE creates a verifier and challenge pair so only the client that initiated the authorization can exchange the authorization code for tokens, mitigating code interception attacks.

• Strict redirect URI validation

  Clients must pre-register exact redirect URIs. The authorization server performs exact matching during authorization to prevent token redirection to attacker controlled endpoints.

• Short lived tokens

  Authorization servers are encouraged to issue short lived access tokens to reduce the impact if a token is leaked.

• Granular scope model

  MCP supports fine grained scopes so clients receive only the permissions they need. Examples of MCP scopes include:

  • mcp:tools:weather
  • mcp:resources:customer-data:read
  • mcp:exec:workflows:*

• Dynamic client registration

  Optional support for automatic registration reduces manual setup and accelerates secure onboarding for new AI agents and clients.

Implementation notes

Implementing OAuth 2.1 for MCP servers follows standard OAuth patterns but with strict enforcement of the security items above. Practical deployments should:

• Expose accurate discovery metadata for clients to consume
• Offer dynamic registration where operationally appropriate
• Enforce PKCE for authorization code exchanges
• Validate redirect URIs exactly
• Issue short lived tokens and consider refresh token policies
• Log authorization and access events for auditing

The MCP specification references practical implementations and examples. One approach mentioned in community examples is to build a simple service, for example a finance sentiment analysis server, and integrate an OAuth 2.1 compliant authorization server or toolkit such as Scalekit to handle the heavy lifting of client registration, token issuance, and validation.