MCP Authorization

Model Context Protocol（MCP） 是一個標準化協定，讓 AI 應用程式能夠與外部工具和資料來源互動。當 MCP Server 需要授權保護時，規範採用 OAuth 2.1 生態系的標準作為授權機制。

MCP 的授權是選擇性的（OPTIONAL），僅適用於 HTTP-based transport。使用 STDIO transport 的實作應從環境變數取得憑證。

本站內容基於 MCP Authorization Specification（2025-11-25）。

三個角色

MCP 授權明確定義了三個角色，對應 OAuth 2.1 的角色：

MCP 角色	OAuth 2.1 角色	職責	涵蓋範圍
MCP Client	Client	代表使用者發出受保護的資源請求	Discovery、Client 註冊、Token 使用、PKCE、Resource Indicators
MCP Server	Resource Server	接受並回應帶有 Access Token 的資源請求	Protected Resource Metadata、Token 驗證、AS 設定
Authorization Server（AS）	Authorization Server	與使用者互動、核發 Access Token	—

AS 可以和 MCP Server 部署在一起，也可以是獨立的服務。

授權流程概覽

sequenceDiagram
    participant C as MCP Client
    participant M as MCP Server
    participant A as Authorization Server（AS）

    C->>M: MCP 請求（無 Token）
    M-->>C: 401 Unauthorized + WWW-Authenticate（可能含 resource_metadata URL）
    Note over C: 從 header 取得 resource_metadata URL，或 fallback 到 well-known URI
    C->>M: 取得 Protected Resource Metadata（RFC 9728）
    M-->>C: 回傳 authorization_servers
    C->>A: 取得 AS Metadata（RFC 8414 或 OIDC Discovery）
    A-->>C: 端點與能力資訊
    Note over C,A: Client 註冊（Client ID Metadata / DCR（RFC 7591）/ 預註冊）
    Note over C,A: Authorization Code + PKCE（OAuth 2.1）+ resource 參數（RFC 8707）
    A-->>C: Access Token
    C->>M: MCP 請求 + Access Token
    M-->>C: MCP 回應

依賴的標準

標準	用途
RFC 7591（DCR）	Client 動態註冊（MAY）
RFC 8414（AS Metadata）	AS 的端點與能力發現
RFC 8707（Resource Indicators）	Token 的 audience 綁定
RFC 9728（Protected Resource Metadata）	MCP Server 公告所屬的 AS
OAuth 2.1（IETF Draft）	授權框架
OIDC Discovery	AS 的端點發現（與 RFC 8414 二選一）
Client ID Metadata Documents（IETF Draft）	Client 自我描述（SHOULD）

Protected Resource Metadata（RFC 9728）

RFC 9728 解決的問題是：Client 怎麼知道一個 Resource Server 是由哪個 AS 保護的？

MCP Server 透過 /.well-known/oauth-protected-resource 提供自己的 metadata，其中 authorization_servers 欄位列出保護它的 AS。Client 拿到 AS 位置後，再去取得 AS Metadata（RFC 8414 或 OIDC Discovery）。

這讓 Resource Server 和 AS 可以部署在不同 domain，一個 Resource Server 也可以列出多個 AS 供 Client 選擇。

此外，RFC 9728 也定義了 WWW-Authenticate header 中的 resource_metadata 參數（Section 5.1），讓 Resource Server 在回傳 401 Unauthorized 時直接告訴 Client 去哪裡取得 metadata，不需要 Client 自己猜測 well-known 路徑。

Client ID Metadata Documents

Client ID Metadata Documents 是一個新的 IETF Draft，讓 Client 使用 HTTPS URL 作為 client_id。這個 URL 指向一個 JSON 文件，描述 Client 的 metadata（名稱、redirect_uris 等）。AS 收到 URL 格式的 client_id 時，直接 GET 該 URL 來取得並驗證 Client 資訊。

與 DCR（RFC 7591） 的差異在於：DCR 是 Client 向 AS 發 POST 請求註冊，AS 需要儲存 Client 資訊；而 Client ID Metadata Documents 是 Client 自己 host metadata，AS 不需要維護註冊狀態。

這個機制特別適合 MCP 的情境——Client 和 Server 事先沒有關係，不需要走註冊流程，Client 只要 host 一個 metadata JSON 就能讓任何 AS 驗證。MCP 規範將此定為 SHOULD，而 DCR 降為 MAY。

Resource Indicators（RFC 8707）

一個 AS 可能同時服務多個 Resource Server。如果核發的 Token 沒有綁定目標，攻擊者可以拿 Server A 的 Token 去存取 Server B。RFC 8707 透過 resource 參數解決這個問題：

• Client 在 authorization request 和 token request 中帶上 resource 參數，指定 Token 要給哪個 Resource Server 使用
• AS 核發的 Token 綁定了 audience（目標 Resource Server）
• Resource Server 驗證 Token 時確認自己是 intended audience，不符就拒絕

在 MCP 的情境中這特別重要，因為同一個 AS 可能同時服務多個 MCP Server。MCP 把 RFC 8707 的要求等級提高了：

	RFC 8707	MCP 2025-11-25
Client 送 resource 參數	SHOULD	MUST
AS 處理 resource 參數	SHOULD	未明確要求，但 Client MUST 送
Server 驗證 Token audience	未定義	MUST（來自 OAuth 2.1）

MCP 規範要求 Client MUST 送 resource 參數，即使 AS 不支援也要送。這確保了當 AS 未來開始支援時，不需要 Client 端做任何修改。

延伸閱讀

• MCP Authorization Specification（2025-11-25）
• OAuth 2.1
• PKCE