$0.02 on this ... I 100% support the OIDC metadata fallback but RFC8414 already mentions this fallback. Supporting that RFC fully would mean that the fallback support is required and wouldn't need to be spelled out explicitly. I think the spec could say something to the effect of:

MUST support RFC8414 to provide at least one mechanism for obtaining AS metadata

... or thereabouts. Edit: Latest spec (2025-06-18) feels like it gets the wording right:

https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#server-metadata-discovery

Maybe the diagram could note the fallback but that's not critical in my mind. Original wording was too prescriptive and current is definitely an improvement.

Related PRs/discussions:

• feat: allow OIDC configuration for OAuth server typescript-sdk#585
• [Specification] Support fallback to OpenID Connect discovery when RFC 8414 isn’t implemented #506

Hi @joshcanhelp thank you for the feedback and suggestions.

However, I believe that treating “support for RFC 8414” as a blanket requirement misses a key architectural consideration, for the following reasons:

As you noted, Section 3 of RFC 8414 states:

Different applications utilizing OAuth authorization servers in application-specific ways may define and register different well-known URI suffixes used to publish authorization server metadata as used by those applications.

The spec mentions that for an auth server used by a specific application (e.g., "example"), its metadata endpoint could be /.well-known/example-configuration. This is for application-specific scenarios. This approach introduces a new challenge: you would need a clearer way for developers to know how to construct this URL from an application's identifier, which would require more specification work to guide auth server discovery.

For the MCP spec, considering its goal of ecosystem compatibility (to adapt to general-purpose auth servers), the more appropriate choice is the default discovery endpoint, which RFC 8414 also mentions:

...many such applications will use the default well-known URI string “/.well-known/oauth-authorization-server”, which is the right choice for general-purpose OAuth authorization servers, and not register an application-specific one.

Regarding /.well-known/openid-configuration, the RFC states:

Some OAuth applications will choose to use the well-known URI suffix “openid-configuration”. As described in Section 5, despite the identifier “/.well-known/openid-configuration”, appearing to be OpenID specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.

So, from the perspective of RFC 8414, there isn't really an "OIDC concept" at play here. The name openid-configuration is just a string that happens to fit the example-configuration pattern.

This distinction frames our decision as a choice between two architectural paths:

1. (The path I rejected): The application-specific route. This would introduce unnecessary complexity by forcing us to define how clients discover these custom URLs.
2. (The path I chose): Supporting a widely adopted, de facto industry standard (OIDC Discovery). This is a pragmatic and robust choice for our ecosystem.

This PR deliberately chooses the second path.

@localden @aaronpk @D-McAdams I'd be interested to hear your point of view on this.

At the end of the day, we want these applications to be able to get the authorization server metadata so they're able to log in. Whether it's one of specific URLs stated or an application-specific one doesn't matter. I don't think we should be deciding that one of those two paths, both of which are currently being used, is the right way when the goal is the same. The question, in my mind, is ... does allowing the application-specific path limit this in any way or affect developers that aren't using it? The RFC solves the problem, I suggest we just point there and leave it at that.

Appreciate the thoughtful conversation, either way!

At the end of the day, we want these applications to be able to get the authorization server metadata so they're able to log in. Whether it's one of specific URLs stated or an application-specific one doesn't matter. I don't think we should be deciding that one of those two paths, both of which are currently being used, is the right way when the goal is the same. The question, in my mind, is ... does allowing the application-specific path limit this in any way or affect developers that aren't using it? The RFC solves the problem, I suggest we just point there and leave it at that.

Appreciate the thoughtful conversation, either way!

If I understand correctly from RFC 8414:

The well-known URI suffix used MUST be registered in the IANA "Well-Known URIs" registry

This limits that even for application-specific URLs, they have to be listed in IANA. Also regarding allowing application specific path (that may not be on the IANA list), could you suggest a few use cases? I'm struggling to understand the value it provides, given that OIDC is the de-facto standard for modern identity providers.

@xiaoyijun
This looks great to me, thanks for putting it up!

Regarding a remaining question from previous PR:

how clients should handle the difference in fields between OICD and OAuth 2.0 AS metadata

AS Metadata and OIDC config requires different fields. See the comparison that @localden shared:
https://gist.github.com/localden/26d8bcf641703c08a5d8741aa9c3336c

I've took a glance and it doesn't seem to me that supporting OIDC requires handling the difference. However could you help with a second eye on checking if any of the differences are required by Auth implementations like modelcontextprotocol/python-sdk@17f9c00?

$0.02 on this ... I 100% support the OIDC metadata fallback but RFC8414 already mentions this fallback. Supporting that RFC fully would mean that the fallback support is required and wouldn't need to be spelled out explicitly. I think the spec could say something to the effect of:

@joshcanhelp I doubt falling back to OIDC discovery is same as the fallback mentioned in the authorization server metadata spec. This is much noticeable in scenarios where issuer has a path component. The Authz server metadata spec defines the URL to be /.well-known/example-configuration/issuer-path-components[1], while OIDC spec defines it as issuer-path-components/.well-known/oidc-configuration[2].

[1] https://datatracker.ietf.org/doc/html/rfc8414#:~:text=formed%20by%20inserting%0A%20%20%20%22/.well%2Dknown/example%2Dconfiguration%22%20between%20the%20host%20and%20path%0A%20%20%20components%20of%20the%20authorization%20server%27s%20issuer%20identifier.
[2] https://openid.net/specs/openid-connect-discovery-1_0.html#:~:text=%C2%A0TOC-,4.1.%C2%A0%20OpenID%20Provider%20Configuration%20Request,-An%20OpenID%20Provider%27s

Hi @LucaButBoring , thanks for your review, I’ve updated the spec to address your concerns, PTAL. ❤️

$0.02 on the subject.

https://modelcontextprotocol.io/specification/draft/basic/authorization#sequence-diagram

Current Auth Server discovery sequence require /.well-known/oauth-authorization-server be hosted under Auth Server domain.
Which is not supported and isn't practical in my opinion for Enterprise Auth Server like Microsoft Entra.
For such centralized and shared Auth Server, it is more practical for Resource Server owner to host the /.well-known/oauth-authorization-server or alternative metadata and ensure its correctness for discovery.

Plus, it opens the possibilities for Resource Server to provide its own Dynamic Client Registration Endpoint while other Endpoints remain pointed to the Enterprise Auth Server.
It reduces the need of create wrapping or re-create Auth Endpoints under Resource Server domain (Which usually isn't allowed under Enterprise Scenario). And the custom Dynamic Client Registration Endpoint give more control to Resource Owner for auditing, also unblock scenario when the compliant Enterprise Auth Server doesn't support Dynamic Client Registration yet. (In that situation, the client returned can be proactively created and permission scoped by Resource Server owner)

Looking forward to learning more about your thoughts and other common Enterprise Auth Server support of this scenario.

For such centralized and shared Auth Server, it is more practical for Resource Server owner to host the /.well-known/oauth-authorization-server or alternative metadata and ensure its correctness for discovery.

Please Correct me if Im missing something, but isn't this already covered by the protected resource metadata spec[1]?

[1] https://datatracker.ietf.org/doc/rfc9728/

For such centralized and shared Auth Server, it is more practical for Resource Server owner to host the /.well-known/oauth-authorization-server or alternative metadata and ensure its correctness for discovery.

Please Correct me if Im missing something, but isn't this already covered by the protected resource metadata spec[1]?

[1] https://datatracker.ietf.org/doc/rfc9728/

It depends on the Auth Server required by Enterprise Context, for Auth Server like Microsoft Entra, there is no support for /.well-known/oauth-authorization-server, and personally I believe that is not practical for such Auth Server which targeted for multi tenants/enterprises.

The current spec's assumption of Auth Server I believe assumed the Auth Server have strong flexibility to the Resource Server owner which isn't the case for Enterprise Scenarios.

Current Auth Server discovery sequence require /.well-known/oauth-authorization-server be hosted under Auth Server domain.

@softnado can you give a specific example of the problem, including what you'd like the issuer to look like? IIUC this isn't a problem today - if you want to use metadata from another server, simply include that server as the issuer.

Also, unless I'm missing something, that's not OIDC-related, so we can spin that off to another RFC if there is a gap there.

One general question - does supporting OIDC for metadata discovery also imply that clients should support the full range of OIDC authentication semantics? In particular, I'm concerned about code_challenge_methods_supported in RFC 8414, which is required when the AS supports PKCE in authorization_code flows (which it must). OIDC does not define the code_challenge_methods_supported field (or indeed PKCE at all), meaning that OIDC authorization servers cannot be used in MCP unless they implicitly follow RFC 8414 already.

Linking @localden's schema comparison for reference.

Hi @LucaButBoring, thanks for raising this important point! You're absolutely right to be concerned about code_challenge_methods_supported and PKCE compatibility.

I did some research into this issue, and here's what I found:

The Core Problem:

• OAuth 2.1 and PKCE specs require authorization servers to support PKCE, but they don't actually define any mechanism for clients to verify this support
• The only reliable way to discover PKCE support is through the code_challenge_methods_supported field in Authorization Server Metadata (RFC 8414 section 2)

code_challenge_methods_supported: JSON array containing a list of Proof Key for Code
Exchange (PKCE) [RFC7636] code challenge methods supported by this
authorization server. ... If omitted, the authorization server does not support PKCE.

• OIDC Discovery spec doesn't define this field, creating a gap for OIDC-only providers

Current Reality:

• Most OIDC providers already include code_challenge_methods_supported in their discovery responses as an extension (Google, GitLab, HuggingFace, Auth0, Logto etc.)
• Since OIDC is an identity layer built on OAuth 2.0, it should logically follow the same discovery patterns
• There's no other reliable mechanism to verify PKCE support (probing with requests is unreliable since servers may silently ignore unknown parameters)

My proposed solution:

Since OIDC is based on OAuth 2.0, there's no alternative reliable discovery mechanism, and MCP absolutely requires PKCE for security, I'm planning to update the spec to require:

• OIDC providers offering MCP compatibility MUST include code_challenge_methods_supported in their discovery responses
• MCP clients MUST verify this field is present.
• This aligns OIDC discovery with OAuth 2.0 Authorization Server Metadata practices

This ensures we never compromise on PKCE security while providing a clear, implementable standard for OIDC providers.

What do you think of this approach?

@LucaButBoring, cc @localden @D-McAdams @dsp-ant

Since OIDC is based on OAuth 2.0, there's no alternative reliable discovery mechanism, and MCP absolutely requires PKCE for security, I'm planning to update the spec to require:

OIDC providers offering MCP compatibility MUST include code_challenge_methods_supported in their discovery responses

• MCP clients MUST verify this field is present.
• This aligns OIDC discovery with OAuth 2.0 Authorization Server Metadata practices
• This ensures we never compromise on PKCE security while providing a clear, implementable standard for OIDC providers.

Yes, this sounds reasonable to me - aligned with this way of handling it for the time being.

@xiaoyijun Do we have implementations for these in Python or Typescript? Per the new process: https://modelcontextprotocol.io/community/sep-guidelines we really would love to see at least one implementation

@xiaoyijun Do we have implementations for these in Python or Typescript? Per the new process: https://modelcontextprotocol.io/community/sep-guidelines we really would love to see at least one implementation

@dsp-ant modelcontextprotocol/python-sdk#1061

This was accepted by @modelcontextprotocol/core-maintainers with a 7 YES votes, 0 NO votes and 1 ABSENT

Since OIDC is based on OAuth 2.0, there's no alternative reliable discovery mechanism, and MCP absolutely requires PKCE for security, I'm planning to update the spec to require:
OIDC providers offering MCP compatibility MUST include code_challenge_methods_supported in their discovery responses

• MCP clients MUST verify this field is present.
• This aligns OIDC discovery with OAuth 2.0 Authorization Server Metadata practices
• This ensures we never compromise on PKCE security while providing a clear, implementable standard for OIDC providers.

Yes, this sounds reasonable to me - aligned with this way of handling it for the time being.

Hi @LucaButBoring , I'm glad this approach sounds reasonable to you.

I've implemented the changes as discussed in the "Authorization Code Protection" section. I also added a clarification about S256 usage since OAuth 2.1 Section 4.1.1 states "If the client is capable of using S256, it MUST use S256, as S256 is Mandatory To Implement (MTI) on the server." So I made sure to include this requirement for MCP clients when they're technically capable of using S256.

Please let me know if this looks good to you!

Hi @pcarleton and @localden , thanks for the earlier approval! I added a small clarification about PKCE support verification based on feedback.

This new commit automatically requires re-review, but the main changes you approved are still intact. Quick look appreciated when you have time!

@xiaoyijun Do we have implementations for these in Python or Typescript? Per the new process: https://modelcontextprotocol.io/community/sep-guidelines we really would love to see at least one implementation

Hi @dsp-ant , yes, I have a related WIP TypeScript SDK PR here: modelcontextprotocol/typescript-sdk#652

Now let this spec is basically settled now, I'll update the SDK implementation to match these new requirements. Will let you know when it's ready!