View a markdown version of this page

支援的身分驗證模式 - Amazon Bedrock AgentCore

支援的身分驗證模式

AgentCore Identity 支援兩種主要身分驗證模式,可處理不同的客服人員使用案例。了解這些模式可協助您為特定代理程式實作選擇正確的方法。

如需這些模式如何套用至特定產業和代理程式類型的詳細範例,請參閱範例使用案例

使用者委派存取 (OAuth 2.0 授權碼授予)

OAuth 2.0 授權碼授予流程可讓客服人員在明確使用者同意的情況下存取使用者特定資料。當客服人員需要存取個人資料或代表特定使用者執行動作時,此模式至關重要。流程包含使用者同意步驟,其中資源擁有者 (使用者) 明確授權代理程式在特定範圍內存取其資料。

重要特性

  • 需要透過授權提示明確取得使用者同意

  • 提供使用者特定資料和資源的存取權

  • 保持客服人員身分與使用者授權之間的明確區隔

  • 支援精細範圍,以限制代理程式可存取的資料

範例案例 – 生產力代理程式需要存取使用者的 Google 行事曆來排程會議、其 Gmail 來傳送電子郵件,以及其 Google Drive 來存放文件。代理程式使用 OAuth 2.0 授權碼授予來取得每個服務的使用者同意,其特定範圍只會限制對必要資料的存取。使用者透過 Google 的同意畫面明確授權代理程式,而 AgentCore Identity 會安全地存放產生的登入資料以供日後使用。

此模式非常適合個人助理客服人員、客戶服務客服人員,以及客服人員需要跨多個服務存取使用者特定資料的任何案例。如需產業特有的詳細範例,請參閱個人助理客服人員客戶服務客服人員

Machine-to-machine身分驗證 (OAuth 2.0 用戶端憑證授予)

OAuth 2.0 用戶端憑證授予流程可在系統之間啟用直接身分驗證,無需使用者互動。當客服人員需要存取非使用者特定的資源,或客服人員自行執行預先授權的使用者同意時,此模式是適當的。

重要特性

  • 不需要使用者互動或同意

  • 代理程式使用自己的登入資料,直接與資源伺服器進行身分驗證

  • 適合背景程序、排程任務和系統層級操作

  • 許可是在客服人員層級定義,而不是為每個使用者定義

範例案例 – 企業資料處理代理程式需要從多個內部系統收集資料、處理資料,並將結果存放在資料倉儲中。代理程式使用 OAuth 2.0 用戶端憑證授予,以使用自己的身分和預先設定的許可直接驗證每個系統。不需要使用者互動,而且當客服人員在排定的間隔內自行取得預先授權的使用者同意時,客服人員可以操作。

此模式非常適合企業自動化代理程式、資料處理工作流程和 DevOps 自動化。如需產業特有的詳細範例,請參閱企業自動化代理程式資料處理和分析代理程式 ,以及開發和 DevOps 代理程式

On-behalf-of杖交換 (OAuth 2.0 權杖交換)

On-behalf-of(OBO) 權杖交換可讓代理程式代表已驗證的使用者存取下游資源伺服器。代理程式會透過傳出憑證提供者交換傳入使用者字符,以交換新的對象範圍存取字符,將使用者的身分和代理程式身分繫結到產生的字符中。下游服務接著可以根據這兩個身分做出授權決策,而不需要使用者進行另一個同意流程。

重要特性

  • 沒有額外的使用者同意 – 傳入使用者字符會直接交換為下游存取字符

  • 將使用者的身分和客服人員 (或工作負載) 的身分傳播到多個躍點,為每個下游服務提供內容,以做出自己的授權決策

  • 支援標準字符交換 (RFC 8693) 或 JWT 授權授予 (RFC 7523),取決於身分提供者

範例案例:存取每個使用者的業務應用程式 – 企業具有內部 HR 應用程式,可強制執行每個使用者存取控制,每個員工只能查看自己的補償和利益資料。公司希望讓員工透過 AI 代理器查詢此應用程式,而不會放寬任何現有的存取政策。

  1. Mike (身分管理員) 會將 HR 應用程式設定為 AgentCore Identity 中的 OAuth 登入資料提供者,包括 OBO 字符交換模式。設定完成後,就不需要每位使用者佈建 - 任何可以向客服人員進行身分驗證的員工都可以透過它連線到 HR 應用程式。

  2. Bob (客服人員開發人員) 新增了呼叫 HR 應用程式的工具。他不會撰寫任何字符交換邏輯或處理用戶端秘密。他GetResourceOauth2Token使用工作負載存取權杖呼叫 ,而 AgentCore Identity 會傳回範圍廣泛的下游權杖。Bob 著重於代理程式如何處理資料,而不是授權的方式。

  3. Sarah (最終使用者) 登入代理程式,並要求它提取她的利益摘要。不會提示她再次登入。在幕後,AgentCore Identity 會將 Sarah 的傳入權杖交換為攜帶其身分的下游存取權杖。HR 應用程式會套用其現有的存取政策,並僅傳回 Sarah 的資料 — 如果她直接存取應用程式,將會看到相同的資料。

此模式非常適合在單一信任網域中周遊多個身分感知服務的企業代理程式。如需授權類型、組態和支援之身分提供者的深入分析,請參閱On-behalf-of權杖交換

選擇正確的身分驗證模式

設計代理程式身分驗證策略時,請考慮這些因素,以判斷最適合的模式:

Factor 使用者委派存取 (OAuth 2.0 授權碼授予) Machine-to-machine身分驗證 (OAuth 2.0 用戶端憑證授予) On-behalf-of杖交換 (OAuth 2.0 權杖交換)

資料擁有權

使用者特定資料 (電子郵件、文件、個人行事曆)

系統或組織擁有的資料 (分析、日誌、共用資源)

使用者特定資料,其中使用者已向客服人員進行身分驗證

使用者互動

使用者存在並且可以提供同意

不需要或不需要使用者互動

使用者已向客服人員進行身分驗證;沒有新的同意提示

操作時間

互動式的即時操作

背景、排程或批次操作

經過身分驗證的使用者啟動的互動式即時操作

許可範圍

許可會因使用者及其同意選擇而有所不同

在客服人員層級定義的一致許可

從傳入使用者字符和下游提供者政策衍生的許可

許多代理程式實作需要其功能不同層面的所有模式。例如,客戶服務代理程式可能會使用使用者委派的存取來擷取特定客戶資料,同時使用machine-to-machine的身分驗證來存取公司知識庫和內部系統。相同的代理程式也可以使用on-behalf-of權杖交換,將使用者的身分傳播到強制執行每個使用者授權的下游服務,而不會再次提示使用者。AgentCore Identity 同時支援所有模式,允許代理程式針對他們需要存取的每個資源使用最適當的身分驗證機制。

所有身分驗證模式都受益於 AgentCore Identity 的核心功能:

  • 保護登入資料儲存,而不會將秘密公開給客服人員程式碼

  • 跨多種資源類型的一致身分驗證界面

  • 安全與合規的全方位稽核記錄

  • 根據身分和內容的精細存取控制

  • 透過 AgentCore SDK 簡化整合