背景
On-Behalf-Of（OBO，代表令牌交換）流程允許中間層服務使用非自身的身分來呼叫下游 Web API。在 OAuth 中這被稱為委派（delegation），目的是將使用者的身分與權限透過請求鏈傳遞。若缺乏身分傳遞，API 呼叫抵達下游服務時會顯示為應用程式本身而非發起動作的用戶，這會破壞稽核軌跡、繞過使用者層級的存取控制，並違反最小權限原則。Microsoft 身分平台文件指出，中間層服務必須從 Microsoft 身分平台取得存取令牌，且僅使用委派範圍（delegated scopes）而非應用程式角色，以防止用戶獲得不應有的資源存取權。 AWS ML Blog 官方原文・learn.microsoft.com
發生什麼事
Amazon Bedrock AgentCore 是一個用於大規模建立、連接和最佳化代理的平台。Amazon 展示了如何配置 AgentCore Gateway 與 Microsoft Entra ID 進行 OBO 令牌交換，使 AI 代理在呼叫 ServiceNow REST API 時能保留呼叫者的身分。此配置在 Gateway 目標上進行，AgentCore Gateway 會在每個請求上執行令牌交換。該模式可應用於其他受 OAuth 保護的 REST API。 AWS ML Blog
重點內容
解決方案架構包含三個關鍵組件：受 Microsoft Entra ID 保護的 AI 代理應用程式、位於代理與 ServiceNow 之間並使用 AgentCore Gateway 實作的 Model Context Protocol（MCP，模型上下文協議）伺服器，以及配置了與 Microsoft Entra ID 綁定的入站 OAuth 整合的 ServiceNow REST API。流程如下：用戶取得 JSON Web Token（JWT，一種用於安全傳輸聲明資訊的開放標準）以呼叫代理；代理使用範圍為自身應用程式註冊的 JWT 向 Gateway 驗證；Gateway 使用 OBO 流程將該令牌交換為範圍為 ServiceNow API 連接器的新令牌，並保留原始用戶身分；ServiceNow 接收有效令牌，其 preferred_username 聲明對應到現有的 ServiceNow 用戶，並套用該用戶的權限。 AWS ML Blog
在技術實現上，AgentCore Gateway 將入站令牌連同代理應用程式的客戶端憑證、目標範圍以及參數 requested_token_use: on_behalf_of 一起發送至 Entra 令牌端點。Entra 驗證呼叫用戶是否已同意委派，然後簽發一個包含原始用戶聲明的 ServiceNow API 新令牌。Microsoft 文件補充說明，若使用共享密鑰（shared secret），請求需包含 grant_type 為 urn:ietf:params:oauth:grant-type:jwt-bearer、client_id、client_secret、assertion（發送至中間層 API 的存取令牌）、scope 以及 requested_token_use 設為 on_behalf_of。若使用憑證，則以 client_assertion_type 和 client_assertion 取代 client_secret。 原文 官方原文・learn.microsoft.com
配置 AgentCore Gateway 時，必須選擇 MCP version 2025-11-25。這是啟用原生 OBO 支援的必要條件，早期 MCP 版本建立的 Gateway 無法開啟原生 OBO 功能。此外，需在 Entra 中建立兩個應用程式註冊：一個代表 AI 代理，另一個代表 ServiceNow API 連接器。在 ServiceNow 端，需建立入站整合並映射用戶聲明（例如將 Entra 的 preferred_username 映射到 ServiceNow 的 Email 欄位）。 AWS ML Blog
對使用者的意義
此功能讓開發者能夠構建符合企業安全規範的 AI 代理。透過保留用戶身分，企業可以確保 AI 代理執行的操作受到與人類用戶相同的權限約束和稽核記錄。這對於需要嚴格存取控制的企業環境至關重要，因為它避免了應用程式擁有過高權限的風險。開發者可以使用 Amazon Bedrock Guardrails 進一步過濾有害內容並驗證代理的輸入輸出。 AWS ML Blog
限制與未定事項
Microsoft 文件指出，OBO 流程僅適用於用戶主體（user principals）。如果服務主體（service principal）請求了僅應用程式令牌並將其發送至 API，該 API 將無法使用 OBO 流程交換代表原始服務主體的令牌，而必須使用客戶端憑證流程。此外，若中間層 API 使用自訂簽名密鑰，下游 API 將無法驗證傳入存取令牌的簽名，導致錯誤。在 ServiceNow 配置中，若 Entra 租戶未在令牌中包含 JTI（JWT ID，用於防止重放攻擊的唯一標識符），可能需要清除 JTI 驗證，或將 Entra 內部使用的 uti 聲明映射到 jti 聲明以提供重放保護。 官方原文・learn.microsoft.com AWS ML Blog
