Anthropic 開放 Claude MCP 連接器企業託管授權，告別逐一 OAuth 同意流程

Anthropic 已宣布，Claude 的模型上下文協定（Model Context Protocol，MCP）連接器正式提供企業託管授權（Enterprise-Managed Authorization，EMA）。根據 2026 年 8 月 24 日的相關報導，企業可把連接器授權從「每位員工各自完成 OAuth 同意」移至公司既有的身分識別與存取管理系統中集中處理。3943

MCP 是一套開放標準，用於把 AI 助手連接至外部工具、商務應用程式、資料儲存庫與開發環境。12 EMA 的重點不是取消企業控管，而是讓管理員能以既有的身分、群組與存取政策，更一致地配置和治理這些連線。

員工與管理員的使用方式有何不同

過去通常需要完成兩個步驟：

1. 管理員先為整個組織啟用或核准某個連接器。
2. 每位員工再個別登入該連接器所屬的服務，完成對方的 OAuth 授權與同意流程。

採用 EMA 後，管理員可在公司的身分提供者（IdP）中配置連接器及其存取政策。只要員工已透過企業現有的群組或政策取得權限，就能沿用目前的單一登入（SSO）工作階段使用已核准的連接器，不必再逐一跳轉瀏覽器，也不必為每個連接器重新按下同意。4962

這並不代表存取權限變得不受控。身分提供者仍是企業作出授權決定的核心系統；管理員可以指定哪些使用者或群組能使用連接器，也能透過同一套集中政策撤銷權限。4142

背後的身分驗證流程

EMA 建立在 MCP 的 Enterprise-Managed Authorization 擴充功能，以及 Identity Assertion JWT Authorization Grant（身分聲明 JWT 授權授予）模式之上。簡化來看，流程如下：

1. 員工透過企業現有的 SSO 系統登入。
2. 身分提供者簽發一份經簽署的身分聲明，格式為 JSON Web Token（JWT）。
3. Claude 將這份聲明提交給 MCP 連接器的授權伺服器。
4. 授權伺服器驗證聲明內容；若企業政策允許存取，便簽發該連接器原本使用的存取權杖。
5. Claude 使用該權杖連線至已核准的 MCP 伺服器。

由於連接器收到的是一份可驗證、且包含企業身分與授權情境的聲明，員工不必再重複完成連接器本身的 OAuth 同意程序。4963

Okta 透過 Cross App Access（XAA）實作這套模式。XAA 是 Okta 對身分提供者介接方式的品牌化實作；MCP 的 EMA 擴充功能則提供開放的協定層，並不表示每個組織都必須採用 Okta 的專有連接器機制。3538

Claude、Claude Code 與 Cowork 都涵蓋在內

MCP 專案的公告指出，Anthropic 已在共用 MCP 層實作這項擴充功能，管理員可跨 Claude、Claude Code 與 Cowork 授權 MCP 伺服器。62 對企業而言，這意味著互動式 Claude 使用情境、開發者工作流程，以及桌面或代理導向的工作，都能採用較一致的授權模型。

Claude Code 另有獨立的企業 MCP 設定控制。Anthropic 表示，管理政策可強制套用工具權限、檔案存取限制與 MCP 伺服器設定，也能由組織管理允許使用的伺服器清單。13 因此，EMA 處理的是「企業身分如何授權連接器」的交接；Claude Code 的受管理設定則可進一步限制使用者一開始能配置哪些 MCP 伺服器。

Anthropic 平台文件另提到，工作負載可使用由組織身分提供者簽發的短期 OIDC 憑證進行驗證，而不必依賴長期有效的靜態 API 金鑰。這與企業身分治理方向相關，但不應與針對連接器的 EMA 流程混為一談。18

目前確認支援哪些連接器？

現有資料確認，與 Okta 計畫相關的初始 MCP 提供者包括：

• Asana
• Atlassian
• Canva
• Figma
• Granola
• Linear
• Supabase

3856

不過，提供的證據不足以建立 2026 年 8 月 24 日全面開放版本的完整連接器清單，也無法可靠區分哪些連接器已經支援、哪些仍屬計畫中的新增項目。除了 Okta 已文件化的 XAA 實作之外，資料也沒有提供完整的身分提供者名單。因此，企業在部署前仍應逐一確認連接器是否可用，以及現有 IdP 是否相容。

這套採用模式並不只與 Okta 有關。身分提供者必須能簽發相應的身分聲明，MCP 連接器開發者則必須讓其授權伺服器能接收並驗證這些聲明。Anthropic 的連接器文件也說明，若開發者希望 MCP 伺服器接受企業身分聲明，並在不要求使用者再次同意的情況下回傳存取權杖，就必須符合相關實作要求。49

Ramp 的角色目前能確認到什麼程度

Okta 曾指出，Ramp、Webflow、HubSpot 等共同客戶參與早期計畫，利用 Okta 管理 Claude 對參與 MCP 提供者之應用程式的存取權限。38

但目前提供的來源沒有交代 Ramp 的具體部署方式、推出規模、使用的連接器組合或量化成果。因此，不能僅憑公告推論 Ramp 已完成何種程度的導入，也不能替其宣稱未經來源證實的成效。

為什麼這項改動對企業部署重要

EMA 處理的是企業大規模導入 AI 連接工具時常見的實務瓶頸。逐一出現的 OAuth 提示會增加新進員工的啟用工作，使存取權限難以標準化，也可能讓管理員必須依賴員工自行完成設定。集中式身分提供者流程則能讓連接器權限依照現有職務、群組與角色政策自動套用。

安全邊界也更加清楚：身分提供者判斷使用者是否有權存取某個連接器，MCP 連接器的授權伺服器則在簽發自身的存取權杖前驗證身分聲明。企業仍然需要逐一評估 MCP 伺服器、採取最小權限原則，並控制使用者可以新增哪些伺服器。Anthropic 的 Claude Code 文件也建議使用可信任的 MCP 伺服器，並透過受管理或受原始碼控制的設定限制伺服器配置。13

因此，這項更新的重點不是「OAuth 消失了」，而是把員工端反覆出現的同意迴圈，改成由企業管理的授權交換，將既有 SSO 政策接到 MCP 連接器存取權限。對希望在團隊中部署 Claude 的公司來說，這有望讓 Claude、Claude Code 與 Cowork 之間的連接器配置更一致，同時保留集中式管理與撤銷權限的能力。4962