aws / aws/amazon-q-developer-cli
Remote HTTP MCP server OAuth fails with false "issuer mismatch" when RFC 9728 resource URL differs from authorization server issuer
まだ誰も着手していません。
- 主要言語
- Rust
- スター
- 2k
- フォーク
- 439
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
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"
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
~/.kiro/settings/mcp.json のリモート HTTP MCP 設定から始め、GitLab Dedicated の例を使って kiro-cli chat で失敗を再現します。OAuth 保護リソースと認可サーバーのディスカバリーを追跡し、次に issuer と異なるリソース URL でも、誤った不一致なしに OAuth フローが完了することを確認します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- rust
- 領域
- api, authentication, cli
- issue の種類
- バグ
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 活発さ
- 活発
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 68/100