In-Depth review of the MCP authorization spec (2025-03-26 edition)

MCP (Model Context Protocol) is an open standard that allows AI models to interact with external tools and services. It's widely adopted by the industry. As MCP supports HTTP-based transport methods, Remote MCP Server will play an increasingly important role in the MCP ecosystem.

Unlike Local MCP Server, which allows each user to run their own server instance, Remote MCP Server requires all users to share the same MCP Server service. This brings up the core problem that MCP Authorization Spec aims to solve: how to allow MCP Server to access user resources on behalf of the user.

This article will analyze the MCP Authorization Spec in depth. It will help you understand the design principles of MCP Authorization Spec and some directions for implementing MCP Authorization. Since this Spec is still evolving, I will share some thoughts based on my personal experience in implementing Authenticator, including:

• Advantages and limitations of OAuth 2.1 as an authorization framework
• Challenges of MCP Server's dual roles as both Authorization Server and Resource Server
• Practical complexity of implementing a full Authorization Server
• Analysis of suitable scenarios for delegated third-party authorization
• Practical trade-offs of Dynamic Client Registration
• Importance of clearly defining MCP Server's resource boundaries

Overview of the MCP Authorization Spec#

MCP Authorization Spec defines the authentication process between MCP Server (Remote) and MCP Client.

I think basing this Spec on OAuth 2.1 is a very reasonable choice. OAuth as an authorization protocol framework solves the problem of how to allow users to authorize third-party applications to access user resources on their behalf. If you are not familiar with OAuth, you can check out AuthWiki-OAuth for more information.

In the MCP Client and MCP Server scenario, it's about "users authorizing MCP Client to access user resources on MCP Server". The "user resources on MCP Server" currently mainly refers to tools provided by MCP Server or resources provided by the backend services of MCP Server.

To implement the OAuth 2.1 authentication process, the protocol requires an MCP Server to provide the following interfaces to work with MCP Client to complete the OAuth 2.1 authentication process:

• /.well-known/oauth-authorization-server: OAuth server meta data
• /authorize: Authorization endpoint, used for authorization requests
• /token: Token endpoint, used for token exchange & refresh
• /register: Client registration endpoint, used for dynamic client registration

The authentication process is as follows:

The Spec also specifies how MCP Server supports delegated authorization through third-party authorization servers.

The example flow in the Spec is as follows (from the Spec content):

In this scenario, although MCP Server delegates authorization to a third-party authorization server, MCP Server still acts as an authorization server for MCP Client. This is because MCP Server needs to issue its own access token to MCP Client.

In my view, this scenario seems more suitable for handling situations where MCP Server proxies MCP Client (user) to access third-party resources (such as Github repos), rather than MCP Server proxying MCP Client (user) to access MCP Server's own resources.

In summary, according to the protocol, MCP Server plays both the roles of Authorization Server and Resource Server in OAuth.

Next, let's discuss the responsibilities of MCP Server as Authorization Server and Resource Server.

MCP Server as authorization service#

When MCP Server acts as Authorization Server, it means that the end user of MCP Client has their own identity on MCP Server. MCP Server is responsible for authenticating this end user and issuing an access token to this end user for accessing MCP Server resources.

The Authorization-related interfaces required by MCP Authorization Spec mentioned above mean that MCP Server must provide an implementation of Authorization Server.

However, implementing Authorization Server functionality on MCP Server is a significant challenge for developers. On one hand, most developers may not be familiar with OAuth-related concepts. On the other hand, there are many details to consider when implementing Authorization Server. If a developer is not from a related field, they may introduce issues such as security problems during implementation.

However, the protocol itself does not limit MCP Server to only implement Authorization Server functionality itself. Developers can completely redirect or proxy these Authorization-related endpoints to other authorization servers. This is no different to MCP Client than MCP Server implementing Authorization Server functionality itself.

You might wonder, should this approach use the delegated third-party authorization method mentioned above?

From my point of view, this mainly depends on whether the users of the third-party authorization service you rely on are the same as the end users of MCP Server. This means that the access token issued to you by the third-party authorization service will be directly consumed by your MCP Server.

• If yes, then you can completely forward Auth-related interfaces in your MCP Server to third-party authorization services.

• If not, then you should use the delegated third-party authorization approach specified in the Spec. You need to maintain a mapping relationship between access tokens issued by MCP Server itself and access tokens issued by third-party authorization services in MCP Server.

I think the delegated third-party authorization approach specified in the protocol is somewhat vague in practical application scenarios. The protocol seems to be letting third parties help MCP Server complete the authorization process, but still requires MCP Server to issue its own Access token. This actually means MCP Server still bears the responsibility of issuing Access tokens as Authorization Server, which is not more convenient for developers. I think it's probably because the authors of the protocol considered that directly returning third-party access tokens to MCP Client would bring some security issues (such as leakage/abuse, etc.).

From my experience, the most suitable scenario for the delegated third-party authorization specified in the protocol should be the scenario of "users authorizing MCP Server to access third-party resources". For example, an MCP Server needs to access a user's Github Repo and deploy the Repo's code to a code deployment platform. In this case, the user needs to authorize MCP Server to access their Github Repo and to access the code deployment platform.

In this scenario, MCP Server is an Authorization Server for MCP Client, because end users have their own identity in MCP Server. MCP Server is a third-party Client for third-party resources (in this case, Github). It needs to get user authorization to access user resources on Github. Between MCP Client and MCP Server, and between MCP Server and third-party resources, user identities are separated. This makes it meaningful to maintain a mapping relationship between access tokens issued by MCP Server itself and access tokens issued by third-party authorization services in MCP Server.

So the delegated third-party authorization protocol in the protocol should solve the problem of "how users authorize MCP Server to access user resources on third-party Resource Servers".

MCP Server as Resource Server#

When MCP Server acts as Resource Server, MCP Server needs to verify whether MCP Client's request carries a valid access token. MCP Server will decide whether to allow MCP Client to access specific resources based on the scope of the access token.

From MCP's definition, the Resource provided by MCP Server should be tools for MCP Client to use. In this scenario, MCP Server only needs to decide whether to provide users with access to certain tools.

But in real-world scenarios, these tools provided by MCP Server also need to interact with the Resource Server of the MCP Server service provider itself. At this time, the access token obtained by MCP Server from the client request needs to be used to access its own Resource Server. In most cases, MCP Server and the Resource Server behind the tools are the same developer. MCP Server is just an interface provided by its own backend resources for MCP Client to use. At this time, MCP Server can share the same access token issued by one Authorization Server with backend resources.

In this case, rather than saying MCP Server is a Resource Server, providing tools and its own service's Resource, it's better to say that the existing Resource Server becomes an MCP Server by providing tools for MCP Client to call.

Including resources provided by its own Resource Server in the Resource provided by MCP Server is more from consideration of real-world scenarios. But I personally still prefer that the Resource provided by MCP Server only has tools used by MCP client, and the resources that tools depend on should be resources obtained by MCP Server from other Resource Servers (including first party and third party). This way, all real-world scenarios can be covered.

How MCP authorization works#

After understanding the responsibilities of MCP Server as Authorization Server and Resource Server, we can know how MCP Authorization specifically works:

Dynamic Client Registration#

The Spec also defines how Authorization Server identifies Clients. OAuth 2.1 provides Dynamic Client Registration Protocol, allowing MCP Client to automatically obtain OAuth client ID without manual user intervention.

According to the Spec, MCP Server should support OAuth 2.0's Dynamic Client Registration Protocol. This way, MCP Client can automatically register with new servers to obtain OAuth client ID. This approach is recommended in MCP scenarios mainly because:

• MCP Client cannot know all possible servers in advance
• Manual registration would cause trouble for users
• It makes connection with new servers seamless
• Servers can implement their own registration policies

However, from a practical perspective, I have some thoughts on the application of Dynamic Client Registration in MCP scenarios:

• In practical OAuth service practices, Client is usually one-to-one corresponding to a specific business App. Dynamically creating Client may not be conducive to effectively managing related resources (users, App, etc.) in OAuth services. OAuth service providers usually hope to have clear control over connected Clients, rather than letting any client register as a Client at will.
• Many OAuth services do not recommend or allow users to dynamically create Clients, because this may lead to abuse of the service. Most mature OAuth service providers (such as GitHub, Google, etc.) require developers to manually register Clients through their developer console, and may also need to provide detailed information about the application, callback URL, etc.
• Manually registering OAuth Client is actually a one-time job during development, not something that every end user needs to do. It will not cause a big burden on developers.
• For Public Client (such as native applications, single-page applications, etc.), we have safer ways to implement OAuth flow without dynamic registration. Client ID combined with PKCE (Proof Key for Code Exchange) can provide a secure enough OAuth flow for Public Client without dynamically creating Client.
• Although the protocol points out that using Dynamic Client Registration can avoid clients needing to know Client ID in advance, in fact, MCP Client always needs to know the address of Remote MCP Server in advance. If so, specifying Client ID while passing in the Remote MCP Server address will not bring much extra trouble. Or, we can also create a convention for MCP Client to ask MCP Server for Client ID, which is not a difficult task.

Although Dynamic Client Registration provides flexibility for the MCP ecosystem in theory, in practical implementation, we may need to consider whether we really need this dynamic registration mechanism. For most service providers, manually creating and managing OAuth Client may be a more controllable and secure way.

Summary#

This article deeply analyzes the design philosophy and implementation challenges of MCP Authorization Spec. As an authorization framework based on OAuth 2.1, this specification aims to solve the key problem of how Remote MCP Server accesses user resources on behalf of users.

Through detailed discussion of MCP Server's dual roles as Authorization Server and Resource Server, as well as the pros and cons of mechanisms such as Dynamic Client Registration and third-party authorization delegation, this article provides thoughts and suggestions from personal experience in implementing Authenticator.

It is worth noting that the MCP authorization specification is still evolving. As a member of the Logto team, we will continue to pay attention to the latest developments of this specification and continuously optimize our implementation solutions in practice to contribute to the secure interaction between AI models and external services.