Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Expose OAuth discovery and registration results for application-owned flows

未关闭
  • 哪里不对？
#1,371 1 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 2 天内回复

@connor4312 已经在做这个了。

开始于 2026年10月16日。

评估

这个 Issue 还没有评估数据。

描述

enhancement P2 ready for work T-security

Could rmcp expose complete discovery and registration results for applications that use its protocol helpers but own the surrounding OAuth lifecycle?

The use case is a client that has its own versioned credential persistence, refresh coordination, consent UI, and HTTP policy. It would like to reuse rmcp's discovery and registration rather than duplicate them, then use the resulting data with lower-level OAuth operations. This is distinct from supplying a custom CredentialStore to the SDK-managed authorization flow.

I checked main at 5d9935d. Two public-API gaps make that composition difficult:

  • AuthorizationMetadataResolution exposes AS metadata and discovery provenance, but not the discovered protected-resource identifier or the selected advertised authorization-server identifier. Resource scopes also remain private, and select_scopes() applies policy rather than returning the separate discovery inputs.
  • AuthorizationManager::register_client() parses the public ClientRegistrationResponse, then returns an OAuthClientConfig and configures the manager. The returned config retains the client ID/secret, but uses the requested redirect URI and drops the server-returned redirect list, client name, and extension fields such as token_endpoint_auth_method.

This means a caller cannot obtain all the resource/issuer/registration facts through those public operations without independently repeating discovery or intercepting and parsing HTTP responses.

An additive approach might be:

  • Extend the existing discovery result with the resource identifier and selected advertised AS identifier, with explicit absence semantics for direct-AS discovery and legacy fallback. If separate challenge/resource scopes are exposed, coordinate that representation with the scope-selection work below. Return facts from the same discovery operation, rather than assembling a result from later mutable manager state.
  • Expose a registration operation returning the existing ClientRegistrationResponse. Define it as registration-only, leaving the current register_client() convenience method to delegate to it and perform its existing configuration step. This should share one request/parsing implementation and preserve the current method's signature.

The registration result would mean the parsed server response, not a claim that every redirect or authentication method is acceptable to the application. Its validation guarantees and handling of secret-bearing fields should be explicit. Existing convenience flows and default policy could remain unchanged.

Related work I found:

  • #1041 already exposes discovery provenance; this would extend that result rather than add a competing API.
  • #962 uses the discovered resource internally, while #1113 proposes an override. Public discovery output is a different requirement.
  • #1352 addresses initial scope selection. I would coordinate any scope-source exposure with it, rather than implement another selection policy or tracker.
  • #1355 / #1358 address DCR authentication-method selection, and #1255 addresses credential restoration. Returning the actual registration response would complement those changes, not replace them.

Potential regression tests would cover a discovered resource different from the configured endpoint; explicit absence on non-PRM paths; ordinary versus challenge-seeded discovery; repeated discovery without stale result fields; preservation of returned registration redirects/name/extensions; one discovery/registration request path; and compatibility of the existing convenience methods.

This proposal does not change issuer-selection/fallback behavior, private-destination policy, automatic retries, or credential persistence. Those can be discussed separately; it should not duplicate the active scope or transport-policy work.

Would additive result APIs along these lines fit the SDK? I can contribute focused discovery-result and registration-result PRs once the intended API boundary is agreed. If an existing issue or planned API already covers these exact outputs, a pointer would help avoid duplicate work.

主要语言
Rust
星标
4k
派生
662
平均合并
3 天 20 小时
30 天内合并 PR
30

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

modelcontextprotocol/rust-sdk 的其他 Issue

查看 modelcontextprotocol/rust-sdk 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。