feat: add LenientOidcDiscoveryMetadataPolicy and Dynamic Client Registration middleware (RFC 7591)#269
feat: add LenientOidcDiscoveryMetadataPolicy and Dynamic Client Registration middleware (RFC 7591)#269simonchrz wants to merge 2 commits intomodelcontextprotocol:mainfrom
Conversation
…allenge_methods_supported Some identity providers (e.g. FusionAuth, Microsoft Entra ID) omit code_challenge_methods_supported from their OIDC discovery response despite supporting PKCE with S256. This policy relaxes the validation to only require authorization_endpoint, token_endpoint, and jwks_uri.
PSR-15 middleware that handles POST /register by delegating to a ClientRegistrarInterface and enriches /.well-known/oauth-authorization-server responses with the registration_endpoint.
simonchrz
requested review from
CodeWithKyrian,
Nyholm and
chr-hertel
as code owners
|
There is an examples for microsoft connection. There is a trouble not only with OIDC discovery. https://github.com/modelcontextprotocol/php-sdk/blob/main/examples/server/oauth-microsoft/MicrosoftOidcMetadataPolicy.php Examples should be also updated if alternative OIDC discovery is accepted. There is also alternative way - in case when code_challenge_methods_supported is missed we can set it's value to default S256 |
| ?StreamFactoryInterface $streamFactory = null, | ||
| ) { | ||
| if ('' === trim($localBaseUrl)) { | ||
| throw new \InvalidArgumentException('The $localBaseUrl must not be empty.'); |
There was a problem hiding this comment.
Please use a lib specific exception here instead of a global one: Mcp\Exception\InvalidArgumentException
| throw new \InvalidArgumentException('The $localBaseUrl must not be empty.'); | |
| throw new InvalidArgumentException('The $localBaseUrl must not be empty.'); |
| /** | ||
| * Interface for OAuth 2.0 Dynamic Client Registration (RFC 7591). | ||
| */ | ||
| interface ClientRegistrarInterface |
There was a problem hiding this comment.
Can you provide a description here, as documentation or reference what is expected here from an interface implementation?
3 participants
Add two features to the HTTP transport layer:
code_challenge_methods_supported
Motivation and Context
LenientOidcDiscoveryMetadataPolicy: Several identity providers (FusionAuth, Microsoft Entra ID) omit code_challenge_methods_supported from
their OIDC discovery response despite fully supporting PKCE with S256. The existing OidcDiscoveryMetadataPolicy rejects these responses,
making it impossible to use the SDK's OAuth transport with those providers without a custom policy. This provides a ready-made workaround.
ClientRegistrationMiddleware: The MCP specification requires servers to support OAuth 2.0 Dynamic Client Registration (RFC 7591) so that MCP
clients can register themselves automatically. This middleware handles POST /register by delegating to a ClientRegistrarInterface
implementation and enriches /.well-known/oauth-authorization-server responses with the registration_endpoint. The ClientRegistrarInterface
keeps the actual registration logic (e.g. calling FusionAuth, storing in a database) pluggable.
How Has This Been Tested?
required fields, empty strings, non-array input
enrichment with registration_endpoint, Cache-Control preservation, non-200 passthrough, non-matching route passthrough, empty localBaseUrl
rejection, trailing slash normalization
Breaking Changes
None. Both features are purely additive — new classes and interfaces only.
Types of changes
Checklist
Additional context
handler classes in tests)
advanced