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

Abierto
  • ¿Algo no está bien?
#20,022 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java, spring
Área
authentication

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)

Lenguaje dominante
Java
Estrellas
9.7k
Forks
6.4k
Merge medio
3 h 11 min
PR fusionados (30 d)
19

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de spring-projects/spring-security

Todos los issues de spring-projects/spring-security

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.