feat(auth): specify OIDC application_type during dynamic client registration (SEP-837)#2784
Open
stefanoamorelli wants to merge 1 commit into
Conversation
SEP-837 requires an MCP client to specify an application_type during OIDC Dynamic Client Registration [1]. When it is omitted, OIDC servers default the client to "web", which conflicts with the loopback redirect URIs that CLI and desktop clients use, so the registration can be rejected. OAuthClientMetadata had no such field and the registration request never sent one, so the SDK hit exactly that default. I add an optional application_type to OAuthClientMetadata and infer it from the redirect URIs when the caller does not set one: loopback and private-use scheme URIs register as "native", a remote https host as "web", and a mix is left unset for the server to decide. An explicit value is always sent as-is. Non-OIDC servers ignore the parameter. Implements [2]. [1]: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/7df71535a0c9b2057d73966bb6b123e684a940cd/docs/specification/draft/basic/authorization/client-registration.mdx#L152-L179 [2]: modelcontextprotocol#2783 Signed-off-by: Stefano Amorelli <stefano@amorelli.tech>
Author
|
The one red check is an unrelated, pre-existing stdio flake ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds an
application_typefield toOAuthClientMetadataand sends it during OAuth Dynamic Client Registration, inferring the value from the client's redirect URIs when the caller does not set one.Closes #2783.
Motivation and Context
SEP-837 requires MCP clients to send an
application_typeduring OIDC Dynamic Client Registration. Omitting it defaults the client to"web", which conflicts with the loopback redirect URIs (localhost,127.0.0.1,::1) that native clients (CLI and desktop apps) use, so the server can reject the registration.Currently
OAuthClientMetadatahas no such field andcreate_client_registration_requestnever sends one, so the client hits that default. This PR adds the field and infers a value from the redirect URIs at registration time: loopback and private-use schemes register as"native", a remotehttpshost as"web", and a mix is left unset for the authorization server to decide. An explicit value is always sent as-is, and non-OIDC servers ignore the parameter. This follows the spec's guidance 1 and mirrors the approach already merged in the Go SDK (modelcontextprotocol/go-sdk#904) and Rust SDK (modelcontextprotocol/rust-sdk#883).How Has This Been Tested?
The full suite passes locally with 100% coverage (
./scripts/test);ruff,ruff format, andpyrightare clean.New unit tests cover the
application_typemodel field, the redirect-URI inference (loopback, IPv4/IPv6 loopback, private-use scheme, remote host, and ambiguous mixes), and thatcreate_client_registration_requestsends the inferred type, preserves an explicit one, and omits an ambiguous one. The auth interaction suite's registration snapshot was updated to includeapplication_type: "native"for its loopback redirect. The conformance suite already covers SEP-837 (src/seps/sep-837.yaml), soconformance.ymlexercises this against the SDK.Breaking Changes
None.
application_typeis optional and defaults toNone; existing callers are unaffected, and registration requests only gain a parameter that OIDC servers expect and non-OIDC servers ignore.Types of changes
Checklist
Additional context
The registration failure SEP-837 describes is already surfaced by
handle_registration_responseas anOAuthRegistrationError, so no new error handling was needed; this PR only ensures the client declares the correct type up front.