auth: resource metadata lookup accepts URLs from non-Bearer challenges

已关闭 适合新手
  • 哪里不对？
#1,379 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@jay23606 已经在做这个了。

开始于 2026年10月12日。

  • #1396 来自 @jay23606 —— 未关闭

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
82/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
go
领域
authentication, backend-api-design

调研方向

阅读 resourceMetadataURLFromChallenges，并将其筛选逻辑与 scopesFromChallenges 和 errorFromChallenges 进行比较。运行 issue 中给出的包级回归测试，然后将其添加到 helper 现有的测试中。当非 Bearer challenge 被忽略且返回 Bearer challenge 的资源元数据 URL 时，即为完成。

由索引模型根据 Issue 内容生成。

描述

Describe the bug

auth.resourceMetadataURLFromChallenges returns the first resource_metadata auth-param without checking the challenge scheme. The adjacent scopesFromChallenges and errorFromChallenges helpers correctly restrict their lookups to Bearer challenges.

As a result, a mixed response such as:

WWW-Authenticate: Basic resource_metadata="https://basic.example/metadata", Bearer resource_metadata="https://mcp.example/metadata"

causes AuthorizationCodeHandler to discover OAuth metadata from https://basic.example/metadata, even though resource_metadata is an MCP Bearer-challenge parameter and the Bearer challenge points elsewhere.

To Reproduce

On main at 944ac19, this package-level test fails:

func TestResourceMetadataURLFromChallengesIgnoresNonBearer(t *testing.T) {
	challenges := []oauthex.Challenge{
		{Scheme: "basic", Params: map[string]string{"resource_metadata": "https://basic.example/metadata"}},
		{Scheme: "bearer", Params: map[string]string{"resource_metadata": "https://mcp.example/metadata"}},
	}
	if got, want := resourceMetadataURLFromChallenges(challenges), "https://mcp.example/metadata"; got != want {
		t.Fatalf("resourceMetadataURLFromChallenges() = %q, want %q", got, want)
	}
}

The current result is https://basic.example/metadata.

Expected behavior

Only a Bearer challenge should supply resource_metadata, matching the filtering already used for scope and error. The current MCP authorization examples attach resource_metadata to the Bearer challenge, and RFC 6750 defines Bearer challenge parameters in WWW-Authenticate.

Additional context

The fix should be a small, unexported behavior correction: require c.Scheme == "bearer" in resourceMetadataURLFromChallenges and add the mixed-challenge regression test above. I would be happy to send that PR if this approach looks right.

Environment: go-sdk main at 944ac19, Go 1.25.0, macOS/arm64.

AI assistance disclosure: I used Codex to inspect the auth flow and draft the reproducer; I reviewed the source, specification references, and issue text.

主要语言
Go
星标
5.3k
派生
607
平均合并
1 天 17 小时
30 天内合并 PR
80

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

modelcontextprotocol/go-sdk 的其他 Issue

查看 modelcontextprotocol/go-sdk 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。