MCP Specification · 2026-07-28 · zh-TW

授權

Authorization · Overview

HTTP-based MCP transport 的 OAuth 2.1 授權、scope、resource indicator、token 與 step-up authorization 規則。

English original

介紹（Introduction）

目的與範圍（Purpose and Scope）

MCP 在 transport 層提供授權能力，讓 MCP 用戶端能代表 resource owner 存取受保護的 MCP server。本規範定義 HTTP-based transport 的授權流程。

協定要求（Protocol Requirements）

Authorization 對 MCP implementation 是 OPTIONAL（選用）。若實作授權：

使用 HTTP-based transport 的 implementation SHOULD（應該）遵循本規範。
stdio transport SHOULD NOT（不應）使用本規範，而應從 environment 取得 credentials。
其他 transport MUST（必須）遵循該協定既有的 security best practices。

本機制建立在 OAuth 2.1、Bearer Token、Authorization Server Metadata、Resource Indicators、Protected Resource Metadata、Issuer Identification，以及 Client ID Metadata Documents 等標準之上。

角色（Roles）

MCP server：扮演 OAuth 2.1 resource server，接受並驗證 access token 後處理 protected resource request。
MCP client：扮演 OAuth 2.1 client，代表 resource owner 發出 protected resource request。
Authorization server：必要時與使用者互動，並簽發供 MCP server 使用的 access token。Authorization server 可以與 resource server 同站，也可以是獨立服務。

總覽（Overview）

Authorization server MUST（必須）實作 OAuth 2.1，並對 confidential 與 public client 採取適當安全措施。
Authorization server 與 MCP client SHOULD（應該）支援 OAuth Client ID Metadata Documents。
雙方 MAY（可以）支援 RFC 7591 Dynamic Client Registration；但 DCR 已 deprecated，只保留做不支援 Client ID Metadata Documents 的 authorization server 之相容方案。
MCP server MUST（必須）提供 RFC 9728 Protected Resource Metadata；MCP client MUST（必須）使用它進行 authorization server discovery。
Authorization server MUST（必須）至少提供 RFC 8414 OAuth Authorization Server Metadata 或 OpenID Connect Discovery 其中一種 discovery；MCP client MUST（必須）能處理兩者。

授權伺服器探索（Authorization Server Discovery）

MCP server 透過 OAuth 2.0 Protected Resource Metadata 公告其 authorization server；MCP client 再透過 authorization server metadata discovery 找出 authorization endpoint、token endpoint 與支援能力。實作 MUST（必須）遵循「Authorization Server Discovery」子頁的規範性 discovery requirements。

用戶端註冊（Client Registration）

開始 authorization flow 前，MCP client MUST（必須）先透過 Client ID Metadata Documents、pre-registration 或 Dynamic Client Registration 取得 client ID。選擇順序與 binding 規則見「Client Registration」子頁。

Scope 選擇策略（Scope Selection Strategy）

MCP server SHOULD（應該）在 401 Unauthorized 的 WWW-Authenticate challenge 中帶上 scope，讓 client 知道目前操作真正需要的 permissions。

Challenge 中的 scope 與 Protected Resource Metadata 的 scopes_supported 之間可能是子集、超集或完全不同集合；client MUST NOT（不得）假設兩者存在固定集合關係，並 MUST（必須）把 challenge 的 scope 視為當前操作的 authoritative requirements。重新授權時，client SHOULD（應該）把這些 scope 與先前已取得的 scope 一起要求，以免取得新權限時失去其他操作所需的既有權限。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

初始授權時，client SHOULD（應該）遵守 least privilege，依下列優先順序選 scope：

優先使用初始 WWW-Authenticate 中的 scope。
若沒有 challenge scope，再使用 Protected Resource Metadata 的 scopes_supported；若該欄位也不存在，則省略 scope parameter。

授權流程（Authorization Flow）

完整流程概念如下：

Client 不帶 token 呼叫 MCP server。
Server 回 401 Unauthorized 與 WWW-Authenticate，client 取得 resource_metadata。
Client 讀取 Protected Resource Metadata，選擇 authorization server。
Client 讀取並驗證 authorization server metadata。
Client 依支援情況使用 pre-registration、Client ID Metadata Document 或 DCR 建立 client identity。
Client 建立 PKCE parameters，帶入 resource 與適當 scopes，開啟 browser authorization flow。
回呼時 client 驗證 issuer（iss），再以 authorization code、code_verifier 與 resource 換取 token。
Client 以 access token 呼叫 MCP server。

授權回應的 issuer 驗證（Authorization Response Validation）

在導向 user-agent 前，client MUST（必須）記錄已驗證 authorization server metadata 中的 issuer，並與同一次 flow 的 PKCE verifier（以及若使用的 state）綁定。

Authorization server SHOULD（應該）依 RFC 9207 在 authorization success 與 error response 中加入 iss；若宣告 authorization_response_iss_parameter_supported: true，就 MUST（必須）實際提供 iss。

收到 authorization response 後，client 在把 authorization code 傳給任何 token endpoint 之前 MUST（必須）依 RFC 9207 套用下列 issuer validation：

Metadata 宣告	Response 有 iss	Client 行為
`true`	有	以 simple string comparison 比對 recorded issuer
`true`	無	拒絕 response
`false` 或未宣告	有	仍比對 recorded issuer
`false` 或未宣告	無	可繼續

比對前 MUST NOT（不得）對 iss 做 scheme/host case folding、default-port elision、trailing slash 或 percent-encoding normalization。若 issuer mismatch，client 也 MUST NOT（不得）採用或顯示該 error response 中的 error、error_description 或 error_uri。

Resource parameter

MCP client MUST（必須）依 RFC 8707 實作 Resource Indicators：

resource MUST（必須）同時出現在 authorization request 與 token request。
resource MUST（必須）識別 client 要使用 token 存取的 MCP server。
resource MUST（必須）使用該 MCP server 的 canonical URI。

Client SHOULD（應該）使用能精確識別 MCP server 的最具體 URI。Canonical form 使用小寫 scheme 與 host，但實作為了 robustness / interoperability SHOULD（應該）接受大寫 scheme 或 host。

https://mcp.example.com/mcp
https://mcp.example.com
https://mcp.example.com:8443
https://mcp.example.com/server/mcp

缺少 scheme 或帶 fragment 的 URI 不是有效 canonical resource identifier。除非 trailing slash 對該 resource 確實具有語意，實作 SHOULD（應該）一致使用不帶 trailing slash 的形式，以提升互通性。Client 無論 authorization server 是否宣告支援，都 MUST（必須）送出 resource。

Access token 使用

Token requirements

Access token handling MUST（必須）符合 OAuth 2.1 Resource Requests 的要求。Client MUST（必須）在每一個 HTTP request 使用 Authorization header：

Authorization: Bearer <access-token>

Access token MUST NOT（不得）放在 URI query string。

Token handling

MCP server 作為 OAuth resource server，MUST（必須）驗證 access token，也 MUST（必須）確認 token 是為自己這個 resource/audience 簽發。Invalid 或 expired token MUST（必須）得到 HTTP 401。

MCP client MUST NOT（不得）把不是該 MCP server authorization server 簽發的 token 送給 MCP server。MCP server MUST（必須）只接受可用於自身 resources 的 token，也 MUST NOT（不得）接受或轉送其他 service 的 token。

Refresh tokens

希望取得 refresh token 的 MCP client：

MUST（必須）在傳輸與儲存時保護 refresh token。
SHOULD（應該）在 client metadata 的 grant_types 加入 refresh_token。
若 authorization server 的 scopes_supported 包含 offline_access，client MAY（可以）要求它。
MUST NOT（不得）假設 authorization server 一定會簽發 refresh token。

MCP server（Protected Resource）SHOULD NOT（不應）在 WWW-Authenticate 或 Protected Resource Metadata 的 resource scope 中要求 offline_access，因為 refresh token 並不是 resource requirement。

錯誤處理（Error Handling）

Server 對 authorization error MUST（必須）回傳適當的 HTTP status code：

HTTP status	用途
`401 Unauthorized`	需要授權、token 無效或已過期
`403 Forbidden`	scope 不足或 permission 不足
`400 Bad Request`	authorization request 格式錯誤

Scope challenge

已持有 token 的 client 若在 runtime 因 scope 不足而失敗，server SHOULD（應該）回 403 Forbidden，並在 WWW-Authenticate: Bearer 中提供：

error="insufficient_scope"
完成當前操作需要的 scope
resource_metadata
選用的 error_description

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="files:write",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

Server SHOULD（應該）一次列出完成目前 operation 所需的所有 scopes，不要一個一個 challenge，避免同一操作觸發多次 authorization round-trip。Server 也 SHOULD（應該）維持一致的 scope inclusion strategy，並考量錯誤 scope 設計造成頻繁使用者互動的 UX 影響。

Step-up authorization

收到 insufficient_scope 後，代表使用者操作的 client SHOULD（應該）嘗試 step-up authorization；代表自己身分運作的 client_credentials client MAY（可以）嘗試 step-up，也可以直接終止該 request。流程如下：

解析 challenge。
把先前要求過的 scopes 與本次 challenge scopes 取 union，避免取得新權限時丟失舊權限。
重新 authorization。
以新 token 重試原始 request，但只應有限次數；持續失敗要視為永久 authorization failure。

Client SHOULD（應該）設定 retry limit 並追蹤 scope upgrade attempts。Server MUST（必須）在判斷 token 是否足夠時考慮 scope hierarchy。

安全考量（Security Considerations）

實作者 MUST（必須）遵循 Authorization Security Considerations 子頁，包括 token audience binding、token theft、HTTPS、PKCE、mix-up attack、open redirect、Client ID Metadata Document security、confused deputy 與 token passthrough 禁止等要求。

MCP Authorization Extensions

Core authorization 之外還可以有獨立 extension。這些 extension 是 optional、additive、composable，且可以獨立版本化；採用 extension 不應破壞 core protocol behavior。