ClientRegistrations: an opt-in fromIssuerLocation that reads RFC 8414 first, for MCP clients

Aperta
#20,022 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java, spring

Direzione di ricerca

Start with ClientRegistrations.fromIssuerLocation and the discovery URL logic it uses, to see how the OpenID Connect and RFC 8414 documents are fetched and parsed in order. The proposal adds a separate fromOAuth2IssuerLocation that tries RFC 8414 first and moves on after a 200 that fails to parse or names another issuer, leaving the existing method unchanged. Done means the new method passes tests for both reported cases, with the existing tests still green. The maintainers have not yet decided whether this should be added at all, so confirm that before writing code.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

status: waiting-for-triage

Problem

ClientRegistrations.fromIssuerLocation(issuer) reads the OpenID Connect document first, then the RFC 8414 document. MCP clients must read RFC 8414 first (MCP authorization spec, 2025-11-25). When the two documents differ, an MCP client gets the wrong one.

Two real cases:

  • Clerk (https://clerk.higgsfield.ai): the OIDC document has no registration_endpoint. The RFC 8414 document has one. Dynamic client registration fails.
  • https://api.getprospect.com: the OIDC document answers 200 but is not valid OIDC metadata (no jwks_uri). fromIssuerLocation throws on the parse error and never reads the valid RFC 8414 document.

Proposal

Add an opt-in method that tries the RFC 8414 URL first. It fixes both cases. fromIssuerLocation does not change.

/**
 * Same as {@link #fromIssuerLocation(String)}, but tries the RFC 8414 endpoint first, as the
 * <a href="https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-server-metadata-discovery">MCP authorization spec</a>
 * requires.
 */
public static ClientRegistration.Builder fromOAuth2IssuerLocation(String issuer) {
	Assert.hasText(issuer, "issuer cannot be empty");
	return getBuilder(issuer, oauth(issuer), oidcRfc8414(issuer), oidc(issuer));
}

If you agree, I can send a PR with tests.

Related

  • spring-ai-community/mcp-security#23: the same OIDC-first order in resource-server discovery. A 200 HTML page at /.well-known/openid-configuration stops it.
  • #19342: MCP discovery order on the authorization-server side.

Our workaround

We shadow ClientRegistrations with a copy of the 7.1.2 source, with this order change, and pin it to 7.1.2 with a test.

(issue generated with AI assistance)

Lingua principale
Java
Stelle
9.7k
Fork
6.4k
Merge medio
3h 11m
PR unite (30g)
19

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di spring-projects/spring-security

Tutte le issue di spring-projects/spring-security

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.