授權伺服器探索

本頁說明 MCP server 如何向 MCP client 公告所屬 authorization server，以及 client 如何找出 authorization endpoint、token endpoint 與 authorization server capabilities。

Authorization server 位置

MCP server MUST（必須）實作 OAuth 2.0 Protected Resource Metadata（RFC 9728）。它回傳的 metadata document MUST（必須）包含至少一個 authorization server 的 authorization_servers 欄位。

Protected Resource Metadata 可以列出多個 authorization servers；要選哪一個由 MCP client 決定。每一個 authorization server 都是獨立的 OAuth server，client ID 也只在簽發它的 authorization server 中有效。

因此 client MUST（必須）為每個 authorization server 分開保存 registration state、client credentials 與 tokens，且 MUST NOT（不得）假設一個 authorization server 的 credentials 可拿去另一個 server 使用。

Protected Resource Metadata discovery

MCP server MUST（必須）提供下列至少一種 discovery 方式：

1. WWW-Authenticate header：回 401 Unauthorized 時，在 Bearer challenge 的 resource_metadata 放入 metadata URL。
2. Well-known URI：依 RFC 9728 提供 metadata。例如 MCP endpoint 為 https://example.com/public/mcp 時，可以使用 https://example.com/.well-known/oauth-protected-resource/public/mcp；也可在 root 提供 https://example.com/.well-known/oauth-protected-resource。

MCP client MUST（必須）支援兩者。如果解析到 WWW-Authenticate 中的 resource_metadata，就必須優先使用該 URL；否則依序嘗試 endpoint-path well-known URI，再嘗試 root well-known URI。

MCP client MUST（必須）能解析 WWW-Authenticate 並正確處理 MCP server 的 401 Unauthorized。Server 也可以在 challenge 中加入 scope，指出存取目前 resource 所需的 scopes。

Authorization server metadata discovery

MCP 使用 RFC 8414 定義的預設 oauth-authorization-server well-known suffix，不另外定義 MCP 專用 suffix。為了同時與 OAuth Authorization Server Metadata 與 OpenID Connect Discovery 互通，client MUST（必須）依 issuer URL 型態嘗試多個 endpoint。

Issuer URL 含 path

例如 issuer 為 https://auth.example.com/tenant1 時，client MUST（必須）依下列順序嘗試：

1. https://auth.example.com/.well-known/oauth-authorization-server/tenant1
2. https://auth.example.com/.well-known/openid-configuration/tenant1
3. https://auth.example.com/tenant1/.well-known/openid-configuration

Issuer URL 不含 path

例如 issuer 為 https://auth.example.com 時，client MUST（必須）依序嘗試：

1. https://auth.example.com/.well-known/oauth-authorization-server
2. https://auth.example.com/.well-known/openid-configuration

Metadata 驗證

取得 metadata document 後，MCP client MUST（必須）依 RFC 8414 或 OpenID Connect Discovery 驗證。最重要的是：document 中的 issuer MUST（必須）與 client 用來建立 well-known URL 的 issuer identifier 完全相同。

例如從 https://attacker.example/.well-known/oauth-authorization-server 取得的 document 若宣告 "issuer": "https://honest.example"，client MUST NOT（不得）使用它。

Discovery 流程

1. Client 先不帶 token 呼叫 MCP server。
2. Server 回 401；若帶 resource_metadata，client 直接使用該 URL。
3. 若沒有 resource_metadata，client 依序 probe endpoint-path 與 root Protected Resource Metadata URI。
4. Client 驗證 resource metadata，並從 authorization_servers 選出 authorization server。
5. Client 依 issuer URL 型態 probe OAuth / OIDC metadata endpoints。
6. 驗證 metadata issuer 後，才進入 OAuth 2.1 authorization flow。