Introduces an update to the current MCP server authorization specification. The goal of this proposal is to shift the implementation from the MCP server being an OAuth Provider (OP) to a Resource Provider (RP) that uses an external identity provider (IdP) as the "golden path."

Proposal credits (authors, contributors, and reviewers)

A massive thank you to folks that helped craft, review, and evolve this proposal - @dksmetters, @will-bartlett, @tolginator, @CaitieM20, @annaji-msft, @halter73, @hpsin, @wdawson, @dasiths, @dsp-ant, @TylerLeonhardt, @calclavia, @cliffhall, @aaronpk, @irvinebroque, @freiadr, @jspahrsummers and many other folks who have dedicated their time, attention, and energy to look through this change.

Pull request reviewers

Special shout-out to folks that helped review this PR: @aaronpk, @connor4312, @nbarbettini, @identitymonk, @ciamshrek, @PieterKas, @mcguinness, @max-stytch, @pwwpche, @dickhardt, @blowdart, @pcarleton, @mattchenderson

TL;DR

Compared to the current specification, we suggest:

1. Move to integration with third-party identity providers (IdP) as the default rather than implement their own OAuth Provider.
2. Move the IdP discovery mechanism by the client to WWW-Authenicate instead of a server-hosted metadata document.
3. Move the PKCE flow to be completed exclusively by the client.

Motivation and Context

The meta-goal of this specification is to simplify how developers integrate OAuth to protect their MCP servers.

Benefits

• Smaller likelihood of developers incorrectly implementing the OAuth specification.
• Proper separation of concerns for PKCE flow.
• More flexibility in defining necessary auth scopes.
• Better controls for preventing credential hijacking through rogue MCP servers.
• Flexible path to using different auth schemes in the future.

How Has This Been Tested?

Tested through prototyping of the current specification vs. the updated one that depends on WWW-Authenticate headers for auth-related discovery processes. No production-ready code developed for this specification at this time.

Breaking Changes

Customers that wrote code that supports the current MCP server authorization specification (e.g., using the TypeScript SDK, which implements the current specification) may need to update their code. This would apply to both servers and clients.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Additional context

• Treat the MCP server as an OAuth resource server rather than an authorization server #205
• Clients should support WWW-Authenticate for authentication rather than just the MCP server's OIDC metadata document #195

Follow-ups/open discussion

• Need for DPoP - DPoP (Demonstrating Proof-of-Possession) prevents token theft attacks by cryptographically binding access tokens to the client that originally requested them, ensuring that even if tokens are intercepted, they cannot be used by attackers from different locations or devices. Implementing DPoP in client applications creates a stronger security posture against various OAuth 2.0 threats like token replay attacks, as each API request includes a unique, signed proof that only the legitimate token holder can generate, significantly reducing the risk surface even if TLS is compromised.
  • This requires additional lift from clients to implement, so in the spec it's labeled as SHOULD instead of MUST, but is this the right call?
• Use of Protected Resource Metadata (PRM) - suggested by @aaronpk, this could be a good alternative to vanilla WWW-Authenticate and would likely map better to an end-to-end OAuth specification. The current proposal for PRM is in draft, however. Is this a path we'd want to pursue?