We’re less than twenty four hours away from the new MCP specification dropping - it will mark the first anniversary of the protocol. In my eyes, this is an important milestone because the protocol is much more mature and stable than it was back at the start of the year.

You’ve likely seen me ramble through the year about the authorization specification (which landed, what feels like, eons ago) and all of the MCP security items. Well, this specification release will also come with some authorization updates.

Client registration #

OAuth Client ID Metadata Documents #

This is, hands down, the most exciting change. Earlier this month I wrote about Client ID Metadata Documents (CIMD) and how they are used with Visual Studio Code. Moving forward, this will be the default way for clients to do registration with authorization servers (AS).

A CIMD-based approach is removing the need to deal with the headache of Dynamic Client Registration (DCR), which has been a thorn in my side for the better part of the year. The challenge with DCR is that because most AS don’t support it, developers had to jump through a bunch of hoops to work around this limitation. This led to a number of uncomfortable conversations where security vulnerabilities were uncovered because, as it turns out, handing security-related responsibilities to people who are not really familiar with the security space is a bad idea.

To implement DCR from scratch, developers often needed to re-implement a bunch of AS logic to “mask” the actual downstream AS. “Problematic approach” doesn’t even begin to describe the situation. In practice, this meant that they needed to learn how to manage client registrations, validate them, implement rate limiting, and so on. If your job is to build an MCP server, this is the last project you want to tackle. On the AS end, DCR was also problematic because it opened the doors for Denial of Service (DoS) attacks, where the same client can have many registrations, and if you don’t have some kind of upper bound control in place, things can get dicey quickly.

CIMD solves that problem by effectively stating that every client now has its own metadata available at a pre-defined URL, managed by said client. The AS can take that registration and properly log it, manage it, and even deny it if it so desires (e.g., a highly-protected corporate environment). Because all revolves around URLs when it comes to CIMD, the AS can also make a bunch of policy decisions based on the domain alone (e.g., allow all *.microsoft.com clients but deny all that are hosted in the *.ru zone). Neat!

Dynamic Client Registration is now not guaranteed #

With CIMD in play, the spec also changed the verbiage around Dynamic Client Registration from SHOULD to MAY support - that is, for backwards compatibility, DCR will still be there, but it’s not guaranteed:

MCP clients and authorization servers MAY support the OAuth 2.0 Dynamic Client Registration Protocol RFC7591 to allow MCP clients to obtain OAuth client IDs without user interaction. This option is included for backwards compatibility with earlier versions of the MCP authorization spec.

If you are an implementer, you don’t need to support DCR from now on.

Preregistration guidance #

We got a lot of questions from folks that weren’t quite sure how to handle scenarios when they want to manage the OAuth process end-to-end with their own client IDs. That is - what if you do not want to go through the registration steps? There are two options that are now well-documented:

  1. You can rely on the client itself having been pre-registered with an AS (e.g., how Visual Studio Code is pre-registered with Entra ID). The client ID in this scenario will be hardcoded.
  2. You can have the client provide a UI where customers can enter their own client ID and secret.

You might’ve noticed that Visual Studio Code, Claude Desktop, and ChatGPT already provide affordances to enter the client ID and secret when you connect to a protected MCP server and need to set OAuth up.

Priority order for client registration paths #

With different approaches to registration, the natural next question is - “How do I prioritize each if I want to support multiple?” This is also now explicitly documented. It boils down to:

  1. Use pre-registration, if available.
  2. Use the CIMD-based approach.
  3. Use the DCR-based approach.
  4. If all else fails, just ask the user to provide the client details.

Discovery enhancements #

Clearer path to PRM discovery #

With the release of the last specification version (2025-06-18), we introduced the concept of a Protected Resource Metadata document (see RFC 9728). With this change, MCP servers could now declare what AS they are using, but the discovery relied on the server responding with a WWW-Authenticate header that points to the PRM document via the resource_metadata field. This can work in most scenarios but sometimes it’s not possible to properly embed this metadata.

The spec now encodes the logic for clients to try and get the PRM by following a set of conventions.

OpenID Connect Discovery 1.0 support #

We added OpenID Connect Discovery (OIDC) 1.0 support to get the authorization server metadata. Using this approach allows us to be more flexible about the location of the AS metadata without compromising the steps needed in the authorization flow. This was already well-known, but is now codified in the spec.

Authorization servers now MUST provide at least one of two discovery mechanisms (standard OAuth 2.0 or OIDC).

Scope Management #

Remember how this summer I was hyping up SEP-835? It’s OK if you don’t, but that change introduced support for incremental scope requests in the MCP authorization specification. This capability allows servers to gradually request new scopes on an as-needed basis instead of having everything at once and storing over-permissioned tokens.

We added a few things to the specification that now make it very easy to understand how to accomplish this:

  • Formally introduced Step-Up Authorization Flow for handling insufficient permissions during runtime operations.
  • There is now a Scope Selection Strategy section that outlines how clients can determine what scopes to use.
  • Servers SHOULD include a scope parameter in WWW-Authenticate headers to indicate required scopes. This means that you no longer need to rely on scopes_supported in the PRM as the go-to mechanism for understanding what scopes to request - just lean on the server to tell you.
  • There is also a detailed Scope Challenge Handling section that offers some really crisp guidance on how to handle insufficient scope errors - you will need this if your original token doesn’t have the right scopes from the start.

And in case you missed it, 401 errors are not the only ones you will need to handle - there is now an explicit callout for HTTP 403 Forbidden with insufficient_scope that can happen. This is your regular reminder to always look a bit beyond the HTTP error codes.

Smaller enhancements #

To top all of the above, we’ve also introduced a number of smaller enhancements and clarifications that will help builders ensure that their MCP clients and servers are secure:

  • Proof Key for Code Exchange (PKCE) is now mandatory - clients MUST verify PKCE support before proceeding with authorization. Clients MUST also use S256 code challenge method when technically capable
  • Just piggybacking on the previous point, we added some clarifications on the use of code_challenge_methods_supported in AS metadata to make client decisions around PKCE support easier.
  • Because we added support for CIMD, we also added a fairly extensive Client ID Metadata Document Security section covering SSRF risks, localhost redirect URI risks, and trust policies.

What’s next #

Now we’re just waiting for the spec to drop on November 25th, 2025 - stay tuned for a blog post announcing this on the Model Context Protocol blog. I also would highly recommend you check out our Security Best Practices document that outlines some of the emerging threats around MCP and how to mitigate them.