Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Expose OAuth discovery and registration results for application-owned flows

オープン
  • 何か問題がありますか？
#1,371 コメント 1 件 リアクション 0 件 担当者 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時間
マージ済み PR（30日）
30

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/rust-sdk のほかの issue

modelcontextprotocol/rust-sdk の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。