auth: RequireBearerToken omits error="invalid_token" when a presented token is rejected

已关闭
  • 哪里不对？
#1,497 2 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@xianshujun 已经在做这个了。

开始于 2026年11月5日。

评估

这个 Issue 还没有评估数据。

描述

Checklist
  • I searched the existing issues, and this has not been reported before.
  • This is a real problem that I ran into myself, using the latest release of the SDK.
  • I ran into it in a production system, not in a toy example, a benchmark, or an automated or AI-driven scan of the code.
  • I (a human) examined the relevant SDK code, and wrote or reviewed every line of this report. It is not unreviewed AI output.
  • This report is brief and concise, and sticks to the facts needed to understand the problem.
What happened?

#1134 asked for both RFC 6750 §3.1 error codes in the WWW-Authenticate challenge: insufficient_scope on the 403, and invalid_token on the 401 for a rejected token. #1421 added only insufficient_scope, and #1135, which added both, was closed as a duplicate of #1134 (comment), so the invalid_token half was dropped.

On main, a presented token that the verifier rejects with ErrInvalidToken, or that has expired, still gets a 401 whose challenge is the same as for a request with no credentials:

WWW-Authenticate: Bearer resource_metadata="...", scope="..."

RFC 6750 §3.1 says this challenge should carry error="invalid_token", while §3 says a request with no credentials should carry no error code. With one header for both, a client cannot tell a rejected token from missing credentials.

How to reproduce
  1. Wrap a handler with RequireBearerToken(verifier, &RequireBearerTokenOptions{ResourceMetadataURL: "https://example.com/.well-known/oauth-protected-resource", Scopes: []string{"read"}}), where verifier returns ErrInvalidToken.
  2. Send a request with Authorization: Bearer some-token.
  3. The response is 401 with WWW-Authenticate: Bearer resource_metadata="...", scope="read", the same header a request without an Authorization header gets.

Expected: the challenge for the rejected token also carries error="invalid_token". The challenge for the request without credentials stays as it is.

Where did you hit this?

ThunderID's MCP server (https://github.com/thunder-id/thunderid) protects its /mcp endpoint with RequireBearerToken. We track the endpoint's RFC 6750 conformance in thunder-id/thunderid#4509.

Go MCP SDK version

v1.8.0. Also checked main at f91620f.

Go version

1.27.2

Logs

N/A

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

环境准备

在 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 摘要。