授權安全考量

本頁列出實作 MCP authorization 時 MUST（必須）考慮的安全要求；實作者同時 MUST（必須）遵循 OAuth 2.1 Section 7 的 security best practices。

Token audience binding 與驗證

RFC 8707 Resource Indicators 能在 authorization server 支援此能力時把 token 綁定到預期 resource。為了讓目前與未來的 audience binding 保護成立：

• MCP client MUST（必須）在 authorization request 與 token request 都帶 resource。
• MCP server MUST（必須）驗證收到的 token 確實是為自己這個 audience/resource 簽發。

Server 不得把收到的 MCP client token 當成上游 API token 直接 passthrough。

Token theft

若攻擊者取得 client 儲存、server cache 或 log 中的 token，就可能以看似合法的 request 存取受保護資源。Client 與 server MUST（必須）安全保存 token 並遵守 OAuth storage best practices。

Authorization server SHOULD（應該）簽發短生命週期 access token。對 public client，authorization server MUST（必須）依 OAuth 2.1 要求 rotate refresh token。

通訊安全（Communication Security）

Implementation MUST（必須）遵循 OAuth 2.1 的 communication security requirements，具體包括：

1. 所有 authorization server endpoints MUST（必須）使用 HTTPS。
2. 所有 redirect URI MUST（必須）是 localhost，或使用 HTTPS。

Authorization code 保護

MCP client MUST（必須）實作 PKCE，並在開始 authorization 前確認 authorization server 支援 PKCE。技術上可行時，client MUST（必須）使用 S256 code challenge method。

Client 必須依 metadata 的 code_challenge_methods_supported 判斷支援：

• OAuth Authorization Server Metadata 若缺少此欄位，client MUST（必須）拒絕繼續。
• OIDC Discovery 雖未把此欄位列為標準必需欄位，但 MCP client 仍 MUST（必須）確認它存在；缺少就拒絕。
• 為了符合 MCP，提供 OIDC Discovery 的 authorization server MUST（必須）在 metadata 中加入 code_challenge_methods_supported。

Mix-up attack

當 client 同時與多個 authorization server 互動時，惡意 authorization server 可能企圖讓 client 把另一個 honest server 發出的 authorization code 或 token 傳給自己。MCP client MUST（必須）依 Authorization Overview 的 issuer validation 規則保存並驗證 issuer/iss，避免 mix-up attack。

Open redirection

• MCP client MUST（必須）把 redirect URI 登錄到 authorization server。
• Authorization server MUST（必須）對 pre-registered redirect URI 做 exact match validation。
• MCP client SHOULD（應該）使用並驗證 authorization code flow 的 state；缺少或 mismatch 時應丟棄結果。
• Authorization server MUST（必須）採取措施避免把 user-agent redirect 到不可信 URI。
• Authorization server SHOULD（應該）只在信任 redirect URI 時自動導向；若不信任，MAY（可以）先向使用者說明，並由使用者決定是否繼續。

Client ID Metadata Document security

支援 CIMD 的 authorization server MUST（必須）考慮 OAuth Client ID Metadata Document Section 6 的安全要求。

SSRF 防護

Authorization server 會主動 fetch client 提供的 metadata URL，因此 SHOULD（應該）評估 Server-Side Request Forgery（SSRF）風險，避免藉由 client ID URL 存取內部網路、metadata services 或其他不應公開的資源。

Localhost redirect URI 風險

Client ID Metadata Document 本身無法阻止 localhost URL impersonation。Authorization server：

• SHOULD（應該）對只有 localhost redirect URI 的 client 顯示額外警告。
• MAY（可以）要求額外 attestation。
• MUST（必須）在 authorization 畫面清楚顯示 redirect URI hostname。

Trust policies

Authorization server MAY（可以）依 domain 建立接受 Client ID Metadata Document 的 trust policy。

Confused deputy

作為第三方 API intermediary 的 MCP server 可能遭到 confused deputy attack。使用 static client ID 的 MCP proxy server，在把 dynamically registered client 導向第三方 authorization server 前，MUST（必須）取得使用者對每個 client 的 consent。

Access token privilege restriction

MCP server MUST（必須）依 OAuth 2.1 Section 5.2 在處理 request 前驗證 inbound access token，確認自己是 token 的 intended recipient，並確保不向未授權的一方回傳資料。沒有把該 MCP server 綁為 audience/resource 的 token MUST（必須）被拒絕。

MCP server MUST（必須）只接受明確為自己簽發的 token。若 MCP server 還要呼叫 upstream API，它可以另行扮演 OAuth client，但 upstream token 必須由 upstream authorization server 另外簽發。MCP server MUST NOT（不得）把從 MCP client 收到的 access token passthrough 給 upstream API。

MCP client MUST（必須）用 RFC 8707 resource 明確指定要取得 token 的 target resource，讓 token 無法在不同 service 間任意重用。