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

クローズ
  • 何か問題がありますか？
#1,497 コメント 2 件 リアクション 0 件 担当者 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日 11時間
マージ済み PR（30日）
82

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/go-sdk のほかの issue

modelcontextprotocol/go-sdk の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。