MCP 身份驗證與授權完整指南

MCP 身份驗證負責識別客戶端及其代表的用戶；授權則決定他們能存取哪些工具、租戶、資源和操作。對遙距 HTTP 伺服器，目前的 MCP 規格使用 OAuth 探索、PKCE、資源指標、bearer token 與 audience 驗證。後端仍然必須授權最終資源。

本機 stdio 伺服器使用程序環境，而不是這套 HTTP 授權流程。不要只為了協定形式一致，就把遙距 OAuth 設計搬到 stdio。

遙距 MCP 授權中的角色

MCP 授權規格定義三種角色：

• MCP 客戶端作為 OAuth 客戶端。
• MCP 伺服器作為受保護的資源伺服器。
• 授權伺服器驗證資源擁有者身份並簽發存取權杖。

授權伺服器可以屬於同一項服務，也可以是獨立的身份平台。MCP 伺服器仍要負責驗證權杖和執行存取限制。

從受保護資源開始探索

客戶端在沒有有效授權的情況下調用受保護 MCP 伺服器時，伺服器會傳回 401，並在 WWW-Authenticate 標頭中指向受保護資源中繼數據。這份中繼數據會告訴客戶端，哪些授權伺服器能夠為此資源簽發權杖。

接着，客戶端讀取 OAuth 授權伺服器中繼數據，找出授權和權杖端點。MCP 同時要求受保護資源和授權伺服器中繼數據，因為通用客戶端可能會連線至從未見過的伺服器。

將請求綁定到 MCP 伺服器

客戶端在授權和權杖請求中都會包含 resource 參數，用來識別預定的 MCP 伺服器。MCP 伺服器接着必須確認收到的權杖確實為自己簽發。

這項 audience 綁定能夠避免為某一服務簽發的權杖被拿到另一項服務重播。簽署有效但 audience 錯誤，仍然不能接受。

保護授權碼

公開 MCP 客戶端無法安全儲存 client secret。規格要求使用 Proof Key for Code Exchange，也就是 PKCE，讓啟動流程的客戶端在交換授權碼時，能證明自己持有 verifier。

Redirect URI 必須先登錄並完全相符。客戶端應使用並驗證 state 值，將回調綁定到自己啟動的請求。除 localhost 開發環境的重新導向外，都必須使用 HTTPS。

只透過授權標頭傳送權杖

每個受保護的 HTTP 請求都帶有：

Authorization: Bearer <access-token>

MCP 規格禁止把存取權杖放在查詢字串中。相較標頭，URL 更容易洩漏至瀏覽器紀錄、反向代理日誌、分析系統、螢幕截圖和 referrer 數據。

無效或過期權杖傳回 401；身份有效但權限範圍不足時則傳回 403。

絕對不要把 MCP 權杖傳到下游

存取權杖的 audience 是 MCP 伺服器，伺服器不能把它轉傳給第三方 API。如果工具會調用上游服務，MCP 伺服器應作為另一個 OAuth 客戶端，或取得專供該服務使用的獨立後端憑證。

權杖轉傳會產生 confused deputy 問題，也會破壞 audience 邊界。MCP API 密鑰指南解釋這些上游憑證應放在哪裏。

對用戶、租戶、資源和操作授權

Scope 只是其中一層。驗證權杖後，應按照目前應用程式狀態計算存取權：

1. 目前代表哪一位用戶或服務身份？
2. 哪一個租戶或組織正在使用？
3. 要求的資源是否屬於該租戶？
4. 此身份的角色能否執行這項操作？
5. 這項操作是否需要目前有效的批准或政策決策？
6. 憑證是否仍然有效，而且尚未超過限制？

下游 API 應再次執行資源層級授權。工具被命名為 read_invoice，不代表 API 調用會因聲明而自動變成唯讀。

將高影響批准分開處理

OAuth 同意授予一類存取權，但不應被視為之後每次刪除、購買或大範圍變更的批准。執行影響重大的操作時，應顯示確切資源和副作用。

MCP 工具規格建議在工具調用前清楚顯示內容並取得確認。安全基礎設施指南則為雲端操作加入規劃和套用邊界。

測試失敗情況

也要檢查日誌、錯誤追蹤器、追蹤數據和分析系統是否含有 access token 或 refresh token。即使驗證邏輯正確，只要伺服器記錄憑證，仍然無法保障安全。

追蹤一個權杖直到停止點

從第一個未驗證請求開始，沿着簽發的存取權杖追蹤到 MCP 伺服器完成驗證為止，接着再追蹤獨立的上游憑證。如果同一個權杖跨越兩道邊界，應先修正後再加入工具。

下方提示會產生這份追蹤和缺少的測試，而且不會調用伺服器。