支持的身份验证模式
AgentCore Identity 支持两种主要的身份验证模式，用于解决不同的代理用例。了解这些模式将有助于您为特定的代理实施选择正确的方法。
有关这些模式如何应用于特定行业和代理类型的详细示例，请参阅示例用例。
主题
User-delegated 访问权限（授予 OAuth 2.0 授权码）
OAuth 2.0 授权码授权流程允许代理在获得用户明确同意的情况下访问用户特定的数据。当代理需要访问个人数据或代表特定用户执行操作时，这种模式是必不可少的。该流程包括用户同意步骤，在该步骤中，资源所有者（用户）明确授权代理在特定范围内访问其数据。
主要特性
-
需要用户通过授权提示明确表示同意
-
提供对特定于用户的数据和资源的访问权限
-
明确区分代理身份和用户授权
-
支持限制代理可以访问的数据的细粒度范围
示例场景-生产力代理需要访问用户的 Google 日历来安排会议，访问他们的 Gmail 才能发送电子邮件，访问他们的 Google 云端硬盘来存储文档。代理使用 OAuth 2.0 授权码授予来获取用户对每项服务的同意，其特定范围仅限访问必要的数据。用户通过 Google 的同意屏幕明确授权代理，Ident AgentCore ity 会安全地存储生成的凭据以备将来使用。
这种模式非常适合个人助理代理、客户服务代理以及任何需要访问跨多个服务的用户特定数据的场景。有关特定行业的详细示例，请参阅个人助理代理和客户服务代理。
Machine-to-machine 身份验证（授予 OAuth 2.0 客户端凭证）
OAuth 2.0 客户端凭证授予流程支持在系统之间进行直接身份验证，无需用户交互。当代理需要访问非用户特定的资源时，或者当代理在获得预先授权的用户同意的情况下自行采取行动时，这种模式是合适的。
主要特性
-
无需用户互动或同意
-
代理使用自己的凭据直接向资源服务器进行身份验证
-
适用于后台进程、计划任务和系统级操作
-
权限是在代理级别而不是按用户定义的
示例场景-企业数据处理代理需要从多个内部系统收集数据，对其进行处理，并将结果存储在数据仓库中。代理使用授予的 OAuth 2.0 客户端凭证，使用自己的身份和预先配置的权限直接向每个系统进行身份验证。无需用户互动，当代理按预先授权的用户同意按预定时间间隔行事时，代理就可以进行操作。
这种模式非常适合企业自动化代理、数据处理工作流程和 DevOps 自动化。有关特定行业的详细示例，请参阅企业自动化代理、数据处理和分析代理以及开发和 DevOps 代理。
On-behalf-of 代币交换（OAuth 2.0 代币交换）
On-behalf-of (OBO) 令牌交换使代理能够代表已通过身份验证的用户访问下游资源服务器。代理通过出站凭证提供商将入站用户令牌交换为受众范围内的新访问令牌，将用户的身份和代理的身份绑定到生成的令牌中。然后，下游服务可以根据两个身份做出授权决策，而无需用户通过另一个同意流程。
主要特性
示例场景：访问按用户划分的业务应用程序 — 企业内部有强制按用户访问控制的人力资源应用程序 — 每位员工只能看到自己的薪酬和福利数据。该公司希望让员工通过 AI 代理查询此应用程序，同时不放松任何现有的访问策略。
-
Mike（身份管理员）在 Identity（包括 OBO 令牌交换模式）中 AgentCore 将 HR 应用程序配置为 OAuth 凭证提供者。设置完成后，无需按用户进行配置，任何能够向代理进行身份验证的员工都可以通过该应用程序访问人力资源应用程序。
-
Bob（代理开发者）添加了一个调用 HR 应用程序的工具。他不写任何代币交换逻辑或处理客户机密。他
GetResourceOauth2Token使用工作负载访问令牌调用，Ident AgentCore ity 返回一个限定范围的下游令牌。Bob 关注的是代理如何处理数据，而不是如何获得授权。 -
Sarah（最终用户）登录代理并要求代理提取她的福利摘要。系统不会提示她再次登录。在幕后， AgentCore Identity 将 Sarah 的入站令牌交换为带有她身份的下游访问令牌。人力资源应用程序应用其现有的访问策略，只返回 Sarah 的数据，与她直接访问应用程序时看到的数据相同。
这种模式非常适合在单个信任域中遍历多个身份感知服务的企业代理。要深入了解授权类型、配置和支持的身份提供商，请参阅On-behalf-of 令牌交换。
选择正确的身份验证模式
在设计代理身份验证策略时，请考虑以下因素以确定哪种模式最合适：
| 因素 | User-delegated 访问权限（授予 OAuth 2.0 授权码） | Machine-to-machine 身份验证（授予 OAuth 2.0 客户端凭证） | On-behalf-of 代币交换（OAuth 2.0 代币交换） |
|---|---|---|---|
|
数据所有权 |
User-specific 数据（电子邮件、文档、个人日历） |
系统或组织拥有的数据（分析、日志、共享资源） |
User-specific 数据，其中用户已经通过代理的身份验证 |
|
用户互动 |
用户在场并可以表示同意 |
无需用户互动，也无需用户交互 |
用户已通过代理的身份验证；没有新的同意提示 |
|
操作时机 |
交互式实时操作 |
后台操作、计划操作或批量操作 |
由经过身份验证的用户发起的交互式实时操作 |
|
权限范围 |
权限因用户及其同意选择而异 |
在代理级别定义的一致权限 |
从入站用户令牌和下游提供商策略派生的权限 |
许多代理实现需要所有模式来实现其功能的不同方面。例如，客户服务代理可能使用用户委派的访问权限来检索特定客户的数据，同时使用机器对机器的身份验证来访问公司知识库和内部系统。同一个代理也可以代表令牌交换将用户的身份传播到强制按用户授权的下游服务，而无需再次提示用户。 AgentCore Identity 同时支持所有模式，允许代理对他们需要访问的每个资源使用最合适的身份验证机制。
所有身份验证模式都受益于 AgentCore Identity 的核心功能：
-
在不向代理代码泄露机密的情况下保护凭据存储
-
跨多种资源类型的一致身份验证接口
-
全面的审核记录，确保安全性和合规性
-
Fine-grained 基于身份和上下文的访问控制
-
通过 AgentCore SDK 简化集成
