Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Expose OAuth discovery and registration results for application-owned flows

Offen
  • Stimmt etwas nicht?
#1,371 1 Kommentar 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

@connor4312 arbeitet bereits daran.

Seit 16.10.2026.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

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.

Vorherrschende Sprache
Rust
Sterne
4k
Forks
662
Ø Merge
3 T. 20 Std.
Gemergte PRs (30 T.)
30

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus modelcontextprotocol/rust-sdk

Alle Issues in modelcontextprotocol/rust-sdk

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.