自承载代理身份验证选项
Azure Pipelines 提供了在注册代理时可以使用的多种身份验证选项。 这些身份验证方法仅在代理注册期间使用。 有关代理在注册后如何通信的详细信息，请参阅 代理通信。
| 代理注册方法 | Azure DevOps Services | Azure DevOps Server & TFS |
|---|---|---|
| 个人访问令牌 （PAT） | 支持 | 使用 HTTPS 配置服务器时受支持 |
| 服务主体 (SP) | 支持 | 当前不支持 |
| 设备代码流 (Microsoft Entra ID) | 支持 | 当前不支持 |
| 已集成 | 不支持 | 仅限 Windows 代理 |
| 协商 | 不支持 | 仅限 Windows 代理 |
| 备用（ALT） | 不支持 | 使用 HTTPS 配置服务器时受支持 |
个人访问令牌 （PAT）
代理配置过程中指定 PAT 为身份验证类型，以便在代理注册期间使用个人访问令牌进行身份验证，然后指定一个可用于代理注册的个人访问令牌 (PAT)，且该令牌的作用域为代理池（读取、管理）（或如果是部署组代理，则作用域为部署组（读取、管理））。
如需更多信息，请参阅使用个人访问令牌（PAT）注册代理
服务主体
指定 SP，以便在代理配置期间选择身份验证类型，并在代理注册时使用服务主体进行身份验证。
有关详细信息，请参阅使用服务主体注册代理。
设备代码流
在代理配置过程中，指定身份验证类型为 AAD，以便在代理注册期间使用设备代码流进行身份验证。
有关详细信息，请参阅 使用设备代码流注册代理。
已集成
用于代理注册的集成 Windows 身份验证仅适用于 Azure DevOps Server 和 TFS 上的 Windows 代理注册。
在配置代理时指定集成为身份验证类型，以便在代理注册期间使用集成 Windows 身份验证进行身份验证。
使用已登录用户的凭据通过 Windows 身份验证方案（如 NTLM 或 Kerberos）将 Windows 代理连接到 TFS。
若要使用此方法进行身份验证，必须先配置 TFS 服务器。
登录到运行 TFS 的计算机。
启动 Internet Information Services （IIS） 管理器。 选择 TFS 站点并确保使用有效的提供程序（如 NTLM 或 Kerberos）启用 Windows 身份验证。
谈判
代理注册的协商身份验证方法仅适用于 Azure DevOps Server 和 TFS 上的 Windows 代理注册。
通过 Windows 身份验证方案（如 NTLM 或 Kerberos）以非登录用户身份连接到 TFS。
若要使用此方法进行身份验证，必须先配置 TFS 服务器。
登录到运行 TFS 的计算机。
启动 Internet Information Services （IIS） 管理器。 选择 TFS 站点，并确保使用 Negotiate 提供程序和其他方法（如 NTLM 或 Kerberos）启用 Windows 身份验证。
使用协商和 NTLM 提供程序配置 
备用 (ALT)
代理注册的备用（基本）身份验证方法仅在 Azure DevOps Server 和 TFS 上可用。
使用基本身份验证连接到 TFS。 若要使用此方法，必须先 在 TFS上配置 HTTPS。
若要使用此身份验证方法，必须按如下所示配置 TFS 服务器：
登录到运行 TFS 的计算机。
配置基本身份验证。 请参阅针对使用基本身份验证的 Team Foundation Server 2015 使用
tfx。
注意
根据设计，需要 IIS 匿名身份验证才能使 OAuth 身份验证正常工作。 Azure DevOps 将使用此 OAuth 身份验证实现代理和管道功能。 出于此原因，即使已配置代理，如果禁用匿名身份验证，这些代理将变得不可用。 Azure DevOps 产品已有出色的安全方法。 IIS 中的 TFS/Azure DevOps 服务器应用程序不会允许未经身份验证的请求通过。 这只是让它通过 IIS Front Door 进入应用程序，从而强制 OAuth。 例如，在管道运行中，构建服务器会为每次构建生成一个与该构建相关的 OAuth 令牌，该令牌在构建完成后失效。 因此，即使令牌受到保护，如果泄露，它在构建后也是无用的，这与标识相反。 OAuth 令牌也不可用于由生成过程运行的代码（开发人员签入的单元测试）。 如果依赖于 Windows 服务所用的 Windows 身份，那么在 CI 中运行单元测试的开发人员可能会提升权限，从而访问或删除他们无权操作的代码。