本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 支持的身份验证模式
<a name="common-use-cases"></a>

AgentCore Identity 支持两种主要的身份验证模式，用于处理不同的代理用例。了解这些模式将帮助您为特定的代理实施选择正确的方法。

有关这些模式如何应用于特定行业和代理类型的详细示例，请参阅[示例用例](identity-use-cases.md)。

**Topics**
+ [User-delegated 访问权限（授予 OAuth 2.0 授权码）](#user-delegated-access)
+ [Machine-to-machine 身份验证（OAuth 2.0 客户端凭据授予）](#machine-to-machine-auth)
+ [On-behalf-of 代币交换（OAuth 2.0 代币交换）](#obo-token-exchange)
+ [选择正确的身份验证模式](#choosing-auth-pattern)
+ [On-behalf-of 使用 AgentCore 身份进行代币交换](on-behalf-of-token-exchange.md)

## User-delegated 访问权限（授予 OAuth 2.0 授权码）
<a name="user-delegated-access"></a>

OAuth 2.0 授权码授予流程使代理能够在获得用户明确同意的情况下访问用户特定的数据。当代理需要访问个人数据或代表特定用户执行操作时，这种模式至关重要。该流程包括用户同意步骤，在该步骤中，资源所有者（用户）明确授权代理在特定范围内访问其数据。

 **主要特性** 
+ 需要通过授权提示获得明确的用户同意
+ 提供对用户特定数据和资源的访问权限
+ 保持代理身份和用户授权之间的明确分离
+ 支持精细的作用域，限制代理可以访问的数据

 **示例场景 ** — 生产力代理需要访问用户的 Google 日历来安排会议，访问他们的 Gmail 来发送电子邮件，访问他们的 Google 云端硬盘来存储文档。该代理使用 OAuth 2.0 授权码授予来获得用户对每项服务的同意，其特定范围仅限于访问必要的数据。用户通过 Google 的同意屏幕明确授权代理，I AgentCore dentity 会安全地存储生成的凭据以备将来使用。

这种模式非常适合个人助理代理、客户服务代理以及代理需要访问多个服务中用户特定数据的任何场景。有关特定行业的详细示例，请参阅[个人助理代理](identity-use-cases.md#personal-assistant-agents)和[客户服务代理](identity-use-cases.md#customer-service-agents)。

## Machine-to-machine 身份验证（OAuth 2.0 客户端凭据授予）
<a name="machine-to-machine-auth"></a>

OAuth 2.0 客户端凭据授予流程支持系统间的直接身份验证，无需用户交互。这种模式适用于代理需要访问非用户特定的资源，或者代理在获得预先授权的用户同意后自行行动。

 **主要特性** 
+ 无需用户互动或同意
+ 代理使用自己的凭据直接向资源服务器进行身份验证
+ 适用于后台进程、计划任务和系统级操作
+ 权限是在代理级别定义的，而不是按用户定义的

 **示例场景 **-企业数据处理代理需要从多个内部系统收集数据，对其进行处理，并将结果存储在数据仓库中。该代理使用 OAuth 2.0 客户端凭据授权，使用自己的身份和预先配置的权限直接向每个系统进行身份验证。无需用户交互，并且代理可以在预定时间间隔内在获得预先授权的用户同意的情况下自行采取行动时进行操作。

这种模式非常适合企业自动化代理、数据处理工作流程和 DevOps 自动化。有关特定行业的详细示例，请参阅[企业自动化代理](identity-use-cases.md#enterprise-automation-agents)、[数据处理和分析代理](identity-use-cases.md#data-processing-and-analytics-agents)以及[开发和 DevOps 代理](identity-use-cases.md#development-and-devops-agents)。

## On-behalf-of 代币交换（OAuth 2.0 代币交换）
<a name="obo-token-exchange"></a>

On-behalf-of (OBO) 令牌交换使代理能够代表已通过身份验证的用户访问下游资源服务器。代理通过出站凭证提供商将入站用户令牌交换为新的受众范围的访问令牌，将用户的身份和代理的身份绑定到生成的令牌中。然后，下游服务可以根据两个身份做出授权决策，而无需用户通过其他同意流程。

 **主要特性** 
+ 无需额外的用户同意-入站用户令牌直接交换为下游访问令牌
+ 跨多跳传播用户的身份和代理（或工作负载）的身份，为每个下游服务提供上下文以做出自己的授权决策
+ 支持标准令牌交换 ([RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html)) 或 JWT 授权授予 ([RFC 7523](https://www.rfc-editor.org/rfc/rfc7523.html))，具体取决于身份提供商

 **示例场景：访问每位用户的业务应用程序 ** — 企业拥有一个内部人力资源应用程序，该应用程序强制执行每位用户的访问控制——每位员工只能看到自己的薪酬和福利数据。该公司希望在不放松任何现有访问政策的情况下，让员工通过人工智能代理查询此应用程序。

1.  **Mike（身份管理员）**将 HR 应用程序配置为 Identity（包括 OBO 代币交换模式）中的 AgentCore OAuth 凭证提供商。设置完成后，无需为每个用户进行配置——任何能够向代理进行身份验证的员工都可以通过该代理访问 HR 应用程序。

1.  **Bob（代理开发人员）**添加了一个调用 HR 应用程序的工具。他不编写任何代币交换逻辑或处理客户机密。他使用工作负载访问令牌[`GetResourceOauth2Token`](https://docs.amazonaws.cn/bedrock-agentcore/latest/APIReference/API_GetResourceOauth2Token.html)进行调用， AgentCore Identity 返回一个范围内的下游令牌。Bob 关注的是代理如何处理数据，而不是如何获得授权。

1.  **莎拉（最终用户）**登录代理并要求其提取她的福利摘要。系统不会提示她第二次登录。在幕后， AgentCore Identity 将 Sarah 的入站令牌交换为带有她身份的下游访问令牌。HR 应用程序应用其现有的访问策略，仅返回 Sarah 的数据，与她直接访问该应用程序时看到的数据相同。

这种模式非常适合在单个信任域中遍历多个身份感知服务的企业代理。要深入了解授权类型、配置和支持的身份提供商，请参阅[On-behalf-of 代币交换](on-behalf-of-token-exchange.md)。

## 选择正确的身份验证模式
<a name="choosing-auth-pattern"></a>

在设计代理身份验证策略时，请考虑以下因素来确定哪种模式最合适：


| 因素 | 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 简化集成