本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
使用 OAuth 对内存中的最终用户进行身份验证
亚马逊 Bedrock AgentCore Memory 数据平面仅使用 AWS 签名版本 4 (SigV4) 对呼叫者进行身份验证。当您的后端或代理代表许多用户调用 Memory 时，Memory 只能看到您的后端的 IAM 角色——它无法验证或强制执行给定请求针对的是哪个最终用户。将一个用户的数据与另一个用户的数据分开完全取决于您的应用程序代码在每个请求上设置了正确的命名空间actorId和命名空间；内存层没有任何东西可以阻止请求处理用户 A 读取用户 B 的数据。
通过使用配置为 OAuth (CUSTOM_JWT) 入站身份验证的AgentCore 网关前置内存，您可以添加内存本身所没有的 OAuth 支持。调用者向最终用户的 JWT 提交请求，网关对其进行验证，访问控制策略根据令牌的声明在基础设施层强制隔离，与您的应用程序逻辑无关。然后，网关以其网关执行角色调用 Memory，充当 OAuth-authenticated 调用方和 Memory IAM-authenticated 数据平面之间的桥梁。
注意
本页建立在 AgentCore 内存连接器之上。首先设置带有内存连接器目标的网关。有关更多信息，请参阅通过网关访问 AgentCore 内存。
网关如何将 OAuth 与内存连接起来
当网关在内存连接器目标前使用CUSTOM_JWT入站身份验证时：
-
调用者使用您的 OpenID Connect 提供商颁发的 JWT 持有者令牌向网关发送请求。根据您的应用程序，令牌可以代表最终用户或代理本身，并且可以在其声明中携带最终用户信息。
-
网关根据您配置的提供商对令牌进行验证，令牌的声明（例如
sub和client_id）将作为主标签提供给网关的访问控制策略。 -
如果策略允许请求，则网关会在其网关执行角色（
GATEWAY_IAM_ROLE出站凭据模式）下将其转发到内存数据平面。
提示
在典型的聊天机器人或代理架构中，最终用户不会直接调用 Memory。您的代理或后端服务是 HTTP 调用者，它会将最终用户的 JWT 与每个 Memory 请求一起传递——令牌 “随请求一起传输”。网关对该令牌进行身份验证并根据其声明评估政策，因此，即使代理是拨打电话的实体，也会强制令牌所代表的最终用户进行访问。
这就是为什么精细的访问控制很重要的原因：有了它，您可以确保请求仅到达令牌中携带的属于经过身份验证的最终用户的内存数据，而不是信任代理本身设置正确的actorId命名空间。
使用代理应用程序，您的最终用户可以通过标准的 OAuth 身份提供商（例如 Amazon Cognito 或任何 OpenID Connect 提供商）登录，并且您可以根据经过身份验证的最终用户的身份强制每位用户的内存隔离。您的应用程序不会向最终用户分发 AWS 证书，而且 Memory 无需本机理解 OAuth。
配置CUSTOM_JWT授权方（OpenID Connect 发现网址、允许的受众和客户端以及范围）是一项标准的网关入站授权任务，并非特定于内存。有关授权方配置，请参阅创建 AgentCore 网关。有关 JWT 声明如何映射到AgentCore::OAuthUser主体及其标签，请参阅核心概念。
注意
OAuth (CUSTOM_JWT) 入站仅与GATEWAY_IAM_ROLE出站凭证模式兼容。该CALLER_IAM_CREDENTIALS模式会转发调用者的 IAM 身份，而 JWT-authenticated 调用者不存在该身份，因此在创建目标时会被拒绝。有关完整的兼容性矩阵，请参阅入站和出站身份验证模式。
强制每个用户访问内存
使用 OAuth 对呼叫者进行身份验证使基于身份的授权成为可能，但仅凭身份验证并不能限制呼叫者可以做的事情。任何具有有效令牌的请求仍然可以到达内存资源中的每个参与者、会话和命名空间。为确保每个请求只能访问属于经过身份验证的最终用户（其身份在 JWT 中携带）的内存数据，请添加具有精细访问控制的访问控制策略。有关如何编写这些策略的信息，请参阅内存的Fine-grained 访问控制。
