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

Đang mở
  • Có gì không ổn?
#20,022 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
30/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java, spring
Lĩnh vực
authentication

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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)

Ngôn ngữ chính
Java
Star
9.7k
Fork
6.4k
Merge trung bình
3 giờ 11 phút
Pull request đã merge (30 ngày)
19

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của spring-projects/spring-security

Tất cả issue của spring-projects/spring-security

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.