Remote HTTP MCP server OAuth fails with false "issuer mismatch" when RFC 9728 resource URL differs from authorization server issuer
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 68/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- rust
- 领域
- api, authentication, cli
调研方向
从 ~/.kiro/settings/mcp.json 中的远程 HTTP MCP 配置开始，使用 GitLab Dedicated 示例通过 kiro-cli chat 重现故障。跟踪 OAuth 受保护资源和授权服务器的发现过程，然后验证资源 URL 与 issuer 不同也能完成 OAuth 流程，而不会出现错误的不匹配。
由索引模型根据 Issue 内容生成。
描述
Checks
- I have searched github.com/aws/amazon-q-developer-cli/issues and there are no duplicates of my issue
- I have run
q doctorin the affected terminal session - I have run
q restartand replicated the issue again
Operating system
macOS 26.6.2 (25G83)
Expected behaviour
When connecting to a remote HTTP MCP server that uses OAuth, kiro-cli should follow RFC 9728 (Protected Resource Metadata) and RFC 8414 (Authorization Server Metadata). The MCP resource identifier and the authorization server's issuer are distinct values and are not required to match. The CLI should discover the authorization server listed in the protected-resource metadata and validate its issuer against that authorization server's own metadata document — not against the MCP resource URL. The connection should succeed and complete the OAuth flow, exactly as the Kiro IDE does with the same configuration.
Actual behaviour
kiro-cli rejects the connection with:
GitLab ✗ failed Authorization server issuer mismatch:
expected https://X.gitlab-dedicated.com/api/v4/mcp,
received https://X.gitlab-dedicated.com
The CLI incorrectly expects the authorization server's issuer to equal the MCP resource URL (.../api/v4/mcp). GitLab correctly advertises a resource of https://X.gitlab-dedicated.com/api/v4/mcp with an authorization server / issuer of https://X.gitlab-dedicated.com. These are supposed to differ per spec, so the CLI raises a false mismatch and refuses to connect. The identical configuration works in the Kiro IDE.
Steps to reproduce
-
Configure a remote HTTP MCP server in ~/.kiro/settings/mcp.json that uses OAuth where the authorization server issuer differs from the MCP resource URL. Example (GitLab Dedicated):
"GitLab": {
"type": "http",
"url": "https://X.gitlab-dedicated.com/api/v4/mcp",
"oauthScopes": ["mcp"]
} -
The server's OAuth discovery returns (both spec-compliant):
- GET /.well-known/oauth-protected-resource/api/v4/mcp
{ "resource": "https://X.gitlab-dedicated.com/api/v4/mcp",
"authorization_servers": ["https://X.gitlab-dedicated.com"],
"scopes_supported": ["mcp"] } - GET /.well-known/oauth-authorization-server
{ "issuer": "https://X.gitlab-dedicated.com", ... }
- GET /.well-known/oauth-protected-resource/api/v4/mcp
-
Start a chat / trigger the MCP connection:
kiro-cli chat -
Observe the "Authorization server issuer mismatch" error and the server failing to connect.
Note: The same config connects successfully in the Kiro IDE, confirming the discovery documents are valid and the defect is in the CLI's issuer validation.
Environment
<This will be visible to anyone. Do not include personal or sensitive information>
[q-details]
version = "2.19.2"
hash = "80d5aeb353825e5fbbe66c5e5c07084979af0262"
date = "2026-08-25T02:48:27.049726Z (2d ago)"
variant = "full"
[system-info]
os = "macOS 26.6.2 (25G83)"
chip = "Apple M4 Pro"
total-cores = 14
memory = "24.00 GB"
[environment]
cwd = "/Users/USER"
cli-path = "/Users/USER"
os = "Mac"
shell-path = "/bin/zsh"
shell-version = "5.9"
terminal = "iTerm 2"
install-method = "unknown"
[env-vars]
PATH = "/Users/USER/.local/bin:/Library/Frameworks/Python.framework/Versions/3.10/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/pkg/env/global/bin:/Applications/iTerm.app/Contents/Resources/utilities:/Users/USER/.local/bin"
QTERM_SESSION_ID = "b40ddb9c90db46f1aafbc571a36d5564"
Q_SET_PARENT_CHECK = "1"
Q_TERM = "2.15.2"
SHELL = "/bin/zsh"
TERM = "xterm-256color"
__CFBundleIdentifier = "com.googlecode.iterm2"
- 主要语言
- Rust
- 星标
- 2k
- 派生
- 442
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
aws/amazon-q-developer-cli 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
aws/amazon-q-developer-cli#3898 ·
-
bug: invalid JSON in agent-format.md `allowedTools` Examples block (JS `//` comments + unquoted `@builtin`) breaks copy-paste可能已有人在做 @ken-jo 于 123 天前认领。 未关闭
难度 1/5 1 小时以内 新手友好度 90/100
aws/amazon-q-developer-cli#3851 ·
-
难度 1/5 1 小时以内 新手友好度 72/100
aws/amazon-q-developer-cli#3316 ·
-
难度 2/5 1-3 小时 新手友好度 68/100
aws/amazon-q-developer-cli#3023 · 2 条评论 ·
-
难度 4/5 3-5 天 新手友好度 15/100
aws/amazon-q-developer-cli#3929 ·
查看 aws/amazon-q-developer-cli 的全部 Issue
相似的 Issue
-
proxy: include denial_category in the "proxy request denied" log line可能已有人在做 @sreyas-endor 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 77/100
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 68/100
metasequoiaime/msime#9113 ·
维护者通常 1 天内回复
-
area:desktop priority:p2 type:chore
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
area: supply-chain
难度 1/5 1 小时以内 新手友好度 73/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 67/100