本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
使用 OAuth 將最終使用者驗證為記憶體
Amazon Bedrock AgentCore 記憶體資料平面只會使用 AWS Signature 第 4 版 (SigV4) 驗證發起人。當您的後端或代理程式代表許多使用者呼叫記憶體時，記憶體只會看到後端的 IAM 角色，無法驗證或強制執行指定請求的目標最終使用者。將一個使用者的資料與另一個使用者的資料分開，完全取決於您的應用程式程式碼設定每個請求的正確actorId和命名空間；記憶體層中的任何內容都不會阻止處理使用者 A 的請求讀取使用者 B 的資料。
透過為 OAuth (CUSTOM_JWT) 傳入身分驗證設定的 AgentCore Gateway 前置記憶體，您可以新增記憶體本身沒有的 OAuth 支援。發起人會向最終使用者的 JWT 提供請求、閘道驗證請求，以及存取控制政策會根據字符的宣告強制執行隔離 - 在基礎設施層，與您的應用程式邏輯無關。閘道接著會以其閘道執行角色呼叫記憶體，做為 OAuth 驗證發起人與記憶體 IAM 驗證資料平面之間的橋樑。
注意
此頁面以 AgentCore 記憶體連接器為基礎。首先設定具有記憶體連接器目標的閘道。如需詳細資訊，請參閱透過閘道存取 AgentCore 記憶體。
閘道如何將 OAuth 橋接至記憶體
當閘道在記憶體連接器目標前使用CUSTOM_JWT傳入身分驗證時：
-
發起人會使用 OpenID Connect 供應商發出的 JWT 承載字符，將請求傳送至閘道。根據您的應用程式，字符可以代表最終使用者或代理程式本身，並且可以在其宣告中攜帶最終使用者資訊。
-
閘道會根據您設定的提供者來驗證字符，而且字符的宣告 （例如
sub和client_id) 會變成可供閘道的存取控制政策做為主體標籤使用。 -
如果政策允許請求，閘道會將其轉送至閘道執行角色下的記憶體資料平面 (
GATEWAY_IAM_ROLE傳出憑證模式）。
提示
在典型的聊天機器人或客服人員架構中，最終使用者不會直接呼叫記憶體。您的代理程式或後端服務是 HTTP 呼叫者，它會與每個記憶體請求一起傳遞最終使用者的 JWT — 字符「與」請求一起移動。閘道會驗證該權杖，並根據其宣告評估政策，因此即使代理程式是進行呼叫的實體，權杖代表的最終使用者也會強制執行存取權。
這就是為什麼精細存取控制很重要：透過它，您可以確保請求僅到達屬於權杖中承載之已驗證最終使用者的記憶體資料，而不是信任代理程式設定正確的actorId命名空間本身。
透過 代理程式應用程式，您的最終使用者可以透過標準 OAuth 身分提供者登入，例如 Amazon Cognito 或任何 OpenID Connect 提供者，而且您可以根據已驗證的最終使用者身分強制執行每個使用者的記憶體隔離。您的應用程式不會將 AWS 登入資料分發給最終使用者，而且記憶體不需要原生了解 OAuth。
設定CUSTOM_JWT授權方 (OpenID Connect 探索 URL、允許對象、用戶端和範圍） 是標準閘道傳入授權任務，並非記憶體專用。如需授權方組態，請參閱建立 AgentCore 閘道。如需 JWT 宣告如何對應至AgentCore::OAuthUser委託人及其標籤，請參閱核心概念。
注意
OAuth (CUSTOM_JWT) 傳入僅與GATEWAY_IAM_ROLE傳出憑證模式相容。CALLER_IAM_CREDENTIALS 模式會轉送發起人的 IAM 身分，該身分對 JWT 驗證的發起人不存在，因此在目標建立時會被拒絕。如需完整的相容性矩陣，請參閱傳入和傳出身分驗證模式。
強制每位使用者存取記憶體
使用 OAuth 驗證發起人是使身分型授權成為可能的原因，但僅驗證不會限制發起人可以執行的操作。任何具有有效權杖的請求仍然可以到達記憶體資源中的每個演員、工作階段和命名空間。為了確保每個請求只能存取屬於已驗證最終使用者的記憶體資料 — 其身分在 JWT 中攜帶 — 新增具有精細存取控制的存取控制政策。如需如何撰寫這些政策，請參閱記憶體的精細存取控制。
