Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

insufficient_scope challenge retry doesn't detect expired access token, gives up after one identical retry

オープン
  • 何か問題がありますか？
#2,724 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@its-nott-me がすでに取り組んでいます。

2026年10月16日 から。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
50/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
authentication, tooling

調査の方向性

Start in core/mcp/oauthManager.ts at checkAuthChallengeSatisfied(), and compare the insufficient_scope branch with the token_expired branch, which already calls isAccessTokenProvablyUnexpired(). Then follow recoverFromAuthChallenge() and startWithRecovery() in core/mcp/remote/remoteClientTransport.ts to see why the identical retry is the only path taken. Done means an expired token that gets a 403 insufficient_scope leads to a refresh attempt instead of giving up, with a test covering that case.

索引モデルが issue の本文から書いたものです。

説明

bug
Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

All / shared core

Inspector version

2.11.0

Node version

v24.12.0

Operating system (and browser, for the web client)

Linux (WSL2)

Transport

Streamable HTTP

MCP server under inspection

Remote OAuth-protected server behind AWS Bedrock AgentCore Gateway (CUSTOM_JWT authorizer), negotiated protocol version 2025-03-26

Steps to reproduce

Related: #2051 (closed, fixed in v2.4.0) fixed this exact failure shape — "checkAuthChallengeSatisfied() reports the challenge as already satisfied, so the caller reconnects with the same expired token" — for the token_expired branch, by adding isAccessTokenProvablyUnexpired(). That check was never mirrored into the insufficient_scope branch, which still has the identical gap today.

  1. Connect successfully to an OAuth-protected remote MCP server; let the access token expire naturally (scope unchanged).
  2. Reconnect. Server returns 403 with WWW-Authenticate: Bearer error="insufficient_scope", scope="..." where scope is fully covered by the stored token's own scp.
  3. Inspector's Network tab shows exactly two identical initialize POSTs, both 403, then "Failed to connect" — no token-endpoint request ever appears.
  4. Manually clearing cached OAuth state and reconnecting (fresh login) immediately works, since checkAuthChallengeSatisfied short-circuits to false once no stored tokens exist.
Expected behavior

insufficient_scope satisfaction should also verify the stored access token isn't expired before concluding "satisfied" — or at minimum, a same-token retry that gets the identical 403 again should fall back to attempting a refresh/interactive flow instead of giving up.

Actual behavior

Connection fails outright with no refresh attempt, forcing a full cache-clear and manual re-login.

Logs, errors, or screenshots

When a connect-time 403 challenge is classified as insufficient_scope, OAuthManager.checkAuthChallengeSatisfied() only checks whether the stored token's scope is already a superset of what's required — it never checks whether that stored token is actually still valid/unexpired (unlike the token_expired branch, which explicitly calls isAccessTokenProvablyUnexpired per the #2051 fix).

When a resource server returns 403 insufficient_scope for a token that's simply expired — not actually missing scope (this happens against at least one real world gateway we use fronting an IdP) — this check wrongly reports "satisfied," so handleAuthChallenge tells the transport to just retry with the same (still expired) token. The retry gets the identical 403, retryCount >= 1 trips in RemoteClientTransport.startWithRecovery, and the connection attempt fails outright — no refresh_token grant is ever attempted, and no interactive re-authorization is ever offered.

We confirmed the stored refresh_token was fully valid throughout (a direct refresh_token grant against the IdP succeeded outside of Inspector), so a silent refresh would have resolved the connection transparently had it been attempted.

Relevant code (reading from main, may have shifted):

  • core/mcp/oauthManager.ts — checkAuthChallengeSatisfied()
  • core/mcp/remote/remoteClientTransport.ts — startWithRecovery() / recoverFromAuthChallenge()

How we verified it: Decoded the JWT directly to confirm expiry, replayed the expired token against the gateway to reproduce deterministically, captured the exact HTTP exchange via Inspector's own Network tab, and confirmed the refresh_token itself was still valid via a direct grant against the IdP outside of Inspector.

Already prototyped a fix?

No response

Before you submit
  • I searched existing issues and this is not a duplicate.
  • This is not a security vulnerability report (those go through the private advisory process).
主要言語
TypeScript
スター
11.1k
フォーク
1.5k
平均マージ
4時間 32分
マージ済み PR（30日）
136

環境構築

はじめの一歩

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

modelcontextprotocol/inspector のほかの issue

modelcontextprotocol/inspector の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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