Skip to content

SEP-837: Update authorization spec to clarify client type requirements#837

Merged
mcp-commander[bot] merged 15 commits into
mainfrom
localden/authz-clienttype
Mar 28, 2026
Merged

SEP-837: Update authorization spec to clarify client type requirements#837
mcp-commander[bot] merged 15 commits into
mainfrom
localden/authz-clienttype

Conversation

@localden

Copy link
Copy Markdown
Contributor

Related to this item in VS Code: microsoft/vscode#252226

  • Added OpenID Connect Dynamic Client Registration 1.0 to the list of referenced specifications
  • Added comprehensive guidance for OIDC application_type parameter during Dynamic Client Registration

Comment thread docs/specification/draft/basic/authorization.mdx Outdated
Comment thread docs/specification/draft/basic/authorization.mdx Outdated
Comment thread docs/specification/draft/basic/authorization.mdx Outdated
localden and others added 2 commits July 3, 2025 17:55
Co-authored-by: Nate Barbettini <nathanaelb@gmail.com>
Co-authored-by: Nate Barbettini <nathanaelb@gmail.com>
@dend dend changed the title (spec) Update authorization spec to clarify client type requirements SEP-837: Update authorization spec to clarify client type requirements Aug 20, 2025
@dend dend self-assigned this Aug 20, 2025
@dend dend requested review from a team August 20, 2025 00:41
@dend dend added SEP draft SEP proposal with a sponsor. in-review SEP proposal ready for review. labels Aug 20, 2025
@dend dend assigned localden and unassigned dend Aug 20, 2025
Comment thread docs/specification/draft/basic/authorization.mdx Outdated
@localden localden added final SEP finalized. and removed accepted SEP accepted by core maintainers, but still requires final wording and reference implementation. labels Jun 4, 2026
koic added a commit to modelcontextprotocol/ruby-sdk that referenced this pull request Jun 17, 2026
## Motivation and Context

SEP-837 (modelcontextprotocol/modelcontextprotocol#837, merged for the 2026-07-28 spec release)
updates the authorization spec to require MCP clients to specify an appropriate OIDC `application_type`
(`"native"` vs `"web"`) during Dynamic Client Registration, so the authorization server can apply
the matching redirect URI policy and native and web clients do not collide on redirect URI validation rules.

This mirrors the approach taken by the TypeScript SDK (typescript-sdk#2266) and the Python SDK (python-sdk#2784):

- `MCP::Client::OAuth::Discovery.infer_application_type(redirect_uris)` returns `"native"` when every redirect URI
  is a native-app URI (a custom  non-http(s) scheme per RFC 8252 Section 7.1, or an http(s) URI with a loopback host
  per RFC 8252 Section 7.3) and `"web"` otherwise, including for nil, empty, or unparseable input.
  Loopback detection reuses the existing `loopback_host?` helper, so lookalike hosts such as `localhost.example.com`
  or `127.attacker.com` are not treated as native.
- `Flow#ensure_client_registered` now posts the metadata through the new `registration_client_metadata` helper,
  which merges the inferred `application_type` into the DCR request body only when the user did not set
  one explicitly (symbol or string key); an explicit value always wins.

Resolves #375.

## How Has This Been Tested?

New tests in `test/mcp/client/oauth/discovery_test.rb` cover the inference: loopback http URIs (IPv4, IPv6, `localhost`),
custom schemes, https URIs, mixed lists, the `localhost.example.com` lookalike, nil/empty input, and unparseable URIs.

New tests in `test/mcp/client/oauth/flow_test.rb` assert on the actual DCR request body via WebMock `assert_requested`:
loopback redirect URI registers `"application_type": "native"`, an HTTPS redirect URI registers `"web"`,
and an explicit `application_type` (symbol- or string-keyed) is never overridden.

## Breaking Changes

None. The DCR request body gains an `application_type` member only when the user has not specified one;
RFC 7591 requires authorization servers to accept and use known metadata fields, and OIDC-registration servers
already default this field to `"web"` when absent.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: Accepted

Development

Successfully merging this pull request may close these issues.

6 participants