代理将 OAuth 2.0 协议与联合标识凭据（FIC）启用的专用令牌交换模式配合使用。 所有代理身份验证流程都涉及多阶段令牌交换，其中代理身份蓝图冒充代理身份来执行操作。 本文介绍代理使用的身份验证协议和令牌流。 它涵盖委派场景、自主操作和联合身份凭证模式。 Microsoft 建议您使用我们的 SDK，例如 Microsoft Entra ID Auth SDK (sidecar)，因为这些协议步骤并不容易实现。
所有代理实体都是机密客户端，也可以充当 On-Behalf-Of 方案的 API。 任何代理实体类型都不支持交互式流，确保所有身份验证都通过编程令牌交换而不是用户交互流进行。
Warning
Microsoft 建议使用经认可的 SDK（如 Microsoft.Identity.Web 和 Microsoft Entra ID 身份验证 SDK（sidecar）库）来实现这些协议。 手动实现这些协议非常复杂且容易出错，并且使用 SDK 有助于确保安全性和符合最佳做法。
先决条件
如果还不熟悉，请浏览以下协议文档。
支持的授予类型
以下是代理应用程序支持的授予类型。
代理标识蓝图
代理身份蓝图支持client_credentials为模拟情境启用安全令牌获取。
jwt-bearer授权类型在代理场景中促进令牌交换，从而允许委托模式。
refresh_token 授予允许在用户上下文中进行后台操作，支持长期运行的进程以维护用户授权。
代理标识
代理标识用于 client_credentials 仅限应用的自治操作，从而启用不带用户上下文的独立功能，并模拟用户代理。
jwt-bearer授权类型支持客户端凭据流和代表流（On-Behalf Of，OBO），从而在委派模式方面提供灵活性。
refresh_token 授权可以促进后台用户委托操作，从而允许代理身份在扩展操作中维持用户上下文。
不支持的流
- 代理应用程序模型显式排除某些身份验证模式以维护安全边界。 交互式（
/authorize）流程不支持代理程序，从而确保所有身份验证都以编程方式进行。 - 公共客户端功能不可用，要求所有代理都作为机密客户端运行。
- 可在蓝图上为仅限同意流配置 Web 重定向 URI（
response_type=none），但不能将其用于交互式令牌获取。 在客户端应用程序上配置了完整的重定向 URI 功能。
核心协议模式
代理可以在三种主要模式下运行：
- 代表常规用户在微软 Entra ID 中操作的代理（交互式代理）。 这是常规代理流。
- 在其自身的名义下运行的代理，使用专门为代理创建的服务主体（独立运行）。
- 代理使用专门为这些代理创建的用户主体（例如，代理具有自己的邮箱）自行代表自己操作。
托管标识集成
托管身份是首选凭据类型。 在此配置中，托管标识令牌充当父代理标识蓝图的凭据，而标准 MSI 协议则适用于凭据获取。 此集成允许代理 ID 获得 MSI 安全和管理的全部优势，包括自动凭据轮换和安全存储。
Warning
由于安全风险，客户端机密不应在生产环境中用作代理标识蓝图的客户端凭据。 而是使用更安全的身份验证方法 ，例如将联合标识凭据（FIC）与托管标识 或客户端证书配合使用。 这些方法通过消除直接在应用程序配置中存储敏感机密的需要，从而提供增强的安全性。
Oauth 协议
有三种代理 OAuth 流：
相关内容
- 授予代理程序访问 Microsoft 365 资源的权限 - 关于同意、手动授权及其他授权系统的面向管理员的指南。
- 代理标识令牌声明 - 颁发给代理的令牌的声明参考。