insufficient_scope challenge retry doesn't detect expired access token, gives up after one identical retry
维护者通常 1 天内回复
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 50/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- typescript
调研方向
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 内容生成。
描述
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.
- Connect successfully to an OAuth-protected remote MCP server; let the access token expire naturally (scope unchanged).
- Reconnect. Server returns 403 with WWW-Authenticate: Bearer error="insufficient_scope", scope="..." where scope is fully covered by the stored token's own scp.
- Inspector's Network tab shows exactly two identical initialize POSTs, both 403, then "Failed to connect" — no token-endpoint request ever appears.
- 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.2k
- 派生
- 1.6k
- 平均合并
- 4 小时 56 分钟
- 30 天内合并 PR
- 155
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
modelcontextprotocol/inspector 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 90/100
modelcontextprotocol/inspector#2810 ·
维护者通常 1 天内回复
-
local:gate cannot pass on Windows — pre-existing failures in test:scripts, coverage:web and coverage:mcpdo可能已有人在做 @olaservo 于 2 天前认领。 未关闭bug v2
难度 4/5 3-5 天 新手友好度 45/100
modelcontextprotocol/inspector#2748 · 已指派 1 人 ·
维护者通常 1 天内回复
-
blocked chore v2
难度 4/5 3-5 天 新手友好度 48/100
modelcontextprotocol/inspector#2548 · 1 条评论 ·
维护者通常 1 天内回复
-
blocked chore v2
难度 4/5 3-5 天 新手友好度 52/100
modelcontextprotocol/inspector#2547 · 1 条评论 ·
维护者通常 1 天内回复
-
Create the GitHub App for board writes and security-alert reads, and store its credentials as org secrets可能已有人在做 @cliffhall 于 7 天前认领。 未关闭chore v2
难度 4/5 3-5 天 新手友好度 35/100
modelcontextprotocol/inspector#2544 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
查看 modelcontextprotocol/inspector 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
VictoriaMetrics/victorialogs-datasource#747 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 79/100
维护者通常 1 天内回复
-
bug from-studio
难度 2/5 1-3 小时 新手友好度 62/100
esengine/DeepSeek-Reasonix#14608 ·
维护者通常 1 天内回复
-
triage
难度 2/5 1-3 小时 新手友好度 75/100
getarcaneapp/arcane#4590 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 77/100
Clouditera/VulnHunter#57 ·