feat(auth): specify OIDC application_type during dynamic client registration (SEP-837) - #2784
Closed
stefanoamorelli wants to merge 1 commit into
Closed
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
Copy link
Copy Markdown
Author
|
The one red check is an unrelated, pre-existing stdio flake (test_tool_call_and_notification_round_trip_over_a_stdio_subprocess) that this PR does not touch; it should be fixed by #2773. |
Sorry, something went wrong.
stefanoamorelli
force-pushed
the
sep-837-oidc-dcr-application-type
branch
from
db06b5f to
b20980a
Compare
June 6, 2026 12:38
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>
stefanoamorelli
force-pushed
the
sep-837-oidc-dcr-application-type
branch
from
b20980a to
ecad2fb
Compare
June 8, 2026 19:37
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_type field to OAuthClientMetadata and 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_type during 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 OAuthClientMetadata has no such field and create_client_registration_request never 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 remote https host 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, and pyright are clean.
New unit tests cover the application_type model field, the redirect-URI inference (loopback, IPv4/IPv6 loopback, private-use scheme, remote host, and ambiguous mixes), and that create_client_registration_request sends the inferred type, preserves an explicit one, and omits an ambiguous one. The auth interaction suite's registration snapshot was updated to include application_type: "native" for its loopback redirect. The conformance suite already covers SEP-837 (src/seps/sep-837.yaml), so conformance.yml exercises this against the SDK.
Breaking Changes
None. application_type is optional and defaults to None; 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_response as an OAuthRegistrationError, so no new error handling was needed; this PR only ensures the client declares the correct type up front.