Improving The Model Context Protocol Authorization Spec - One RFC At A Time

Table of Contents

As I started diving deeper into Model Context Protocol (MCP), I also started experimenting a bit more with its authorization capabilities. I quickly learned of a few walls that I kept hitting as I worked on prototyping ways to plug in with identity providers like GitHub (even though it’s not truly an identity provider in the traditional sense of the work) and Entra ID. Some of these issues were documented by Aaron Parecki in his own post - “Let’s fix OAuth in MCP.”

Instead of trying to find workarounds, however viable those might be, myself and a few identity and security experts, along with some folks from the broader MCP community worked on putting together a Request For Comments (RFC) document that aims to simplify and future-proof a bit the current MCP authorization specification. We want your feedback on it.

Check out the RFC on GitHub

What’s the point #

I foresee that for the next few months I will be diving deeper and deeper into the MCP space, because it started permeating everything. Even OpenAI started supporting it.

Yes, it's MCP all the way down. — Yes, it’s MCP all the way down.

With the proliferation of MCP, there is a greater need to make sure that we establish a set of baseline standards that help developers build secure MCP servers as well as MCP clients that can talk to them. The first version of the authorization specification is now a stable part of the 2025-03-26 protocol revision. As I mentioned above, it’s a start, but one that needs a bit more work.

If you weren’t super-immersed in the evolution of MCP and its capabilities, no worries - I can quickly catch you up on why you should care about authorization. Authorization on local MCP servers is probably not as critical at this moment in time, however it is a much-needed capability as we move towards a world of remote MCP servers. That is - hosting a MCP server in the cloud and having the world as the potential market for it. This is both exciting and scary, no?

You can’t just have an open endpoint hosted somewhere that anyone can access with no credentials, unless that’s your intent. The vast majority of developers at a large number of enterprises and startups do not have that intent, though, and want to have some level of protection between their infrastructure, data, and the broader Internet. This is where a robust authorization infrastructure can help.

The current MCP authorization specification sets us on that path, but does require quite a bit of work for a developer to get things right, such as implementing the OAuth 2.1 PKCE flows from scratch. The main drawback there is that most developers are not security experts. They want to expose an API or a capability but don’t always have the required knowledge to build security systems. And they don’t need to - that’s not their primary job, and security is its own extensive field.

That’s why we’re working on improving this position quite a bit. There is a pull request that proposes a shift of the authorization paradigm where the “golden path” (the ideal pattern) for developers to adopt is using established identity providers (IdP) rather than write their own OAuth provider from scratch.

This comes on the heels of two key issues that were tracked in the MCP specification repository:

With the RFC on deck (comments and feedback extremely welcome as we’re iterating on it), there are a few benefits that bring the previous specification to the next level:

Developers don’t need to be experts in OAuth and authorization flows to get things up and running quickly.
Standardization around common OAuth patterns and WWW-Authenticate instead of the MCP server hosting its own authorization server metadata.
Proper separation of concerns for the Proof Key for Code Exchange.
A bit more flexibility for defining necessary authorization scopes.
Better controls for preventing credential hijacking through rogue MCP servers (that is - verify that the requesting resource is allowed by the IdP to acquire tokens).
A good path to enable other authentication schemes in the future that go beyond OAuth.

There’s more work ahead, of course, but it’s a start to help developers build more secure (by default) MCP servers. I’d love if you took some time to review the proposal and see if there are things that should work differently. You don’t need to be a security expert to provide feedback. If you’ve ever worked with any identity provider, take a peek.

Acknowledgements #

I am extremely grateful to the many folks at Anthropic (especially David Soria Parra), Microsoft (this is a coordinated effort with the Developer and Security divisions), and in the broader MCP community who provided feedback on the initial idea and helped shape the RFC. It truly takes a village to write something that will have broad community ramifications, given all the MCP work that’s being done in the industry today.

You can view the latest credits in the RFC post.

As a bonus, I’ll leave you with this brand-new clip from Engineering Festivus: