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 伺服器完成驗證為止，接著再追蹤獨立的上游憑證。如果同一個權杖跨越兩道邊界，應先修正後再加入工具。

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