Azure DevOps 服务 |Azure DevOps Server |Azure DevOps Server 2022
本文重点介绍调用Azure DevOps的应用、脚本和管道的集成身份验证模式。 对新集成使用基于新Microsoft Entra ID的身份验证，因为它提供更强的安全性和更好的长期兼容性。
如果需要涵盖用户登录、治理控件和平台级安全状况的组织级概述，请参阅Azure DevOps的身份验证指南。
对与 Azure DevOps Services 集成的新应用程序使用Microsoft Entra ID身份验证。 请谨慎使用个人访问令牌，仅当Microsoft Entra ID不可用时。
重要
请考虑使用更安全的Microsoft Entra令牌以替代高风险的个人访问令牌。 有关详细信息，请参阅 减少 PAT 使用情况。 查看 身份验证指南 ，以根据需要选择正确的身份验证机制。
OAuth 2.0 和Microsoft Entra ID身份验证仅适用于Azure DevOps服务，而不适用于Azure DevOps Server。
对于本地方案，请使用 .NET 客户端库、Windows 身份验证 或 个人访问令牌。
小窍门
可以在本文的后面部分使用 AI 来帮助完成此任务，也可以参阅 Azure DevOps MCP Server 的文档以启用 AI 协助来开始使用。
比较常见的身份验证选项
使用下表比较应用、脚本和管道的最常见身份验证选项。
| 方法 | 最适用于 | 安全态势 | 凭据管理 | 使用 | 避免何时 |
|---|---|---|---|---|---|
| 托管标识 | Azure托管的自动化，例如Azure Functions、应用服务或虚拟机 | Azure托管工作负荷的最强选项，因为令牌生存期较短，Azure管理标识生命周期 | 没有用于存储或轮换的客户端密码;Azure管理标识和令牌获取 | Azure DevOps服务;将标识添加到Azure DevOps后，Azure托管的工作负荷位于同一Microsoft Entra租户中 | 工作负荷不会在Azure上运行，或者需要未绑定到Azure资源的可移植标识 |
| 服务主体 | 跨多个环境或在外部 CI/CD 系统中Azure外部运行的自动化 | 使用基于证书的身份验证或联合方法并应用最低权限时，强选项 | 除非联合流删除机密，否则管理应用程序标识和任何客户端机密或证书 | Azure DevOps服务;需要Microsoft Entra应用程序标识的应用、脚本和服务 | 可以将托管标识用于同一Azure托管工作负荷，或者该工具仅支持基于 PAT 的身份验证 |
| Azure DevOps服务连接 | Azure Pipelines对Azure DevOps资源的访问权限 | 管道自动化的强选项，因为它使用Microsoft Entra工作负荷标识联合，而不是长期令牌 | Azure DevOps管理服务连接，管道不需要将 PAT 存储在变量中 | Azure DevOps服务;跨组织访问存储库、源或 REST API 的管道 | 此方案不会通过Azure Pipelines |
| 个人访问令牌 (PAT) | 短期的个人脚本、一次性测试或尚未使用基于Microsoft Entra身份验证的旧方案 | 常见选择的最高风险，因为令牌是绑定到用户帐户的长期持有者机密 | 必须手动创建、存储、轮换和撤销令牌 | Azure DevOps服务和Azure DevOps Server;支持 PAT 的 CLI、REST 调用和旧集成 | 集成是生产服务、共享自动化或任何服务主体、托管标识或服务连接可用的方案 |
快速建议
- 当工作负荷在Azure上运行并且Azure可以拥有标识生命周期时，请首先选择托管标识。
- 如果需要应用程序标识，但工作负荷不会在Azure上运行，或者必须跨环境移动，请选择服务主体。
- 当Azure Pipelines需要访问没有 PAT 的Azure DevOps资源时，请选择Azure DevOps服务连接。
- 仅针对不应用更安全选项的个人、临时、旧或Azure DevOps Server方案选择 PAT。
基于场景的身份验证方法
根据应用程序类型和要求选择适当的身份验证方法。
| 应用程序类型 | 说明 | 示例 | 推荐的方法 | 代码示例 |
|---|---|---|---|---|
| Web/桌面应用 | 使用当前框架的交互式应用程序 | React 应用，.NET桌面应用 | Microsoft Entra OAuth与 Microsoft 身份验证库 (MSAL) | 托管客户端控制台应用 |
| 服务/后台应用 | 在没有用户交互的情况下运行的应用程序 | Azure Functions后台服务 | 服务主体与托管身份 | 服务主体 |
| 旧版客户端应用 | 使用客户端库的现有应用程序 | 具有Azure DevOps .NET库的控制台应用 | 使用 OAuth 的 .NET 客户端库 | Client 库控制台应用 |
| 无界面/CLI 应用 | 非交互命令行工具 | 生成脚本，自动化工具 | 设备授权授予流 | 设备配置文件 |
| Azure DevOps扩展 | 在Azure DevOps中运行的扩展 | 自定义仪表板小组件和工作项窗体 | Azure DevOps Web 扩展 SDK | 添加仪表板小部件 |
| Azure DevOps Server应用 | 本地部署的 Azure DevOps Server 集成 | 自定义服务器扩展 | .NET客户端库或Windows身份验证 | Client 库控制台应用 |
| 个人/即席脚本 | 个人使用的快速脚本 | PowerShell 脚本、curl 命令 | 个人访问令牌 | REST API 入门 |
| Azure Pipelines | 从管道访问Azure DevOps | 使用来自不同组织的工件 | Azure DevOps服务连接 | 添加Azure DevOps Microsoft Entra服务连接 |
入门建议
以下部分提供了在不同场景下入门的建议。
新应用程序
- 构建 Azure DevOps 与 Microsoft Entra OAuth 应用集成，以获得最佳安全性和未来的兼容性。
- 在服务对服务方案中使用服务主体或托管标识。
- 避免在生产应用程序中使用个人访问令牌。
现有应用程序
- 计划从个人访问令牌迁移到Microsoft Entra ID身份验证。
- 请考虑 身份验证迁移时间线，以改进Azure DevOps并减少个人访问令牌的使用。
- 根据安全最佳做法查看当前的身份验证方法。
Azure DevOps Server
- 尽可能将 .NET 客户端库与Windows身份验证配合使用。
- 在可接受的情况下，对Azure DevOps Server方案使用个人访问令牌。
- 规划未来的Azure DevOps服务迁移，以利用新式身份验证。
常见问题 (FAQ)
我应使用 Microsoft Entra ID OAuth 或个人访问令牌？
在以下方案中使用 Microsoft Entra ID OAuth：
- 新的应用程序和集成。
- 需要可靠安全性的生产工作负荷。
- 需要企业标识集成的应用程序。
- 合规要求的长期项目。
仅在以下方案中使用个人访问令牌：
- 个人脚本和即席任务。
- 迁移规划过程中的旧版应用程序。
- Azure DevOps Server 中新式身份验证不可用的情况。
我应该使用服务主体或用户委派进行身份验证吗？
在以下情况下使用服务主体或托管标识：
- 生成独立运行的应用程序（后台服务、自动化）。
- 创建不需要用户交互的应用。
- 实现服务到服务通信。
- 构建持续集成和持续交付（CI/CD）管道或自动化工作流。
在以下情况下使用用户委派（OAuth 与用户同意）：
- 为用户代替行动的应用程序。
- 创建交互式应用，让用户使用自己的凭据登录。
- 实现需要用户特定权限的功能。
- 生成尊重用户个人访问权限的应用。
如何对Azure DevOps服务和Azure DevOps Server进行身份验证？
为每个服务创建单独的身份验证路径：
- Azure DevOps Services：使用 Microsoft Entra ID OAuth。
- Azure DevOps Server：将.NET客户端库与Windows身份验证或个人访问令牌配合使用。
requestContext使用该方法检测服务类型，并应用相应的身份验证方法。
为什么我的服务帐户无法访问Azure DevOps API？
下面是影响服务帐户访问的一些常见问题：
- 服务帐户未"实例化"：请使用正确的登录方法。 服务帐户需要交互式登录权限或适当的Microsoft Entra ID注册。
- 权限不足：确保服务帐户具有适当的 Azure DevOps 权限。
- 身份验证方法：使用服务主体或托管标识，而不是尝试作为服务帐户进行身份验证。
如何从个人访问令牌迁移到新式身份验证？
执行以下步骤：
确定应用程序中当前的个人访问令牌使用情况。
选择备用身份验证方法：
- Microsoft Entra ID用户委托方案的 OAuth
- 适用于服务间通信场景的服务主体
- Azure DevOps服务连接
在删除任何个人访问令牌依赖项之前，请彻底测试更改。
监视并验证新的身份验证方法。
为什么我不应该解码或读取认证令牌中的声明？
身份验证令牌的存在只是为了证明调用方 是谁 ， 以及他们有权执行的操作。 它们不是稳定的数据接口或可以依赖的架构。
令牌声明永远不会公开记录，并且Azure DevOps保留随时更改、重命名、删除或加密令牌的权利，而不通知。 从 2025 年夏天开始，Azure DevOps会进一步加密身份验证令牌，这意味着客户端无法读取令牌有效负载。 解码令牌以提取声明的任何应用程序都会失效。
请遵循以下做法，而不是检查令牌声明：
- 将令牌视为不透明 - 在授权标头中传递令牌，但不对其进行解码或检查。
- 使用支持的 REST API — 从 Azure DevOps REST API检索用户或组织数据，该 API 提供稳定的合同和文档。
- 假设任何声明都可以更改 — 如果你发现自己在分析令牌内容以读取值，请改为将该逻辑放到 API 调用中。
这些更改不会影响已将令牌视为不透明的应用程序。
实现过程
为方案选择身份验证方法后，完成实现步骤：
- New applications：构建 Azure DevOps 与 Microsoft Entra OAuth 应用的集成
服务应用程序 ：在 Azure DevOps 中使用服务主体和托管标识 - 个人脚本： 使用个人访问令牌
- Azure Pipelines：使用 Entra 工作负荷标识访问 Azure DevOps
使用 AI 选择身份验证方法
如果在代理模式下将 Azure DevOps MCP 服务器连接到 AI 代理，则可以使用自然语言提示获取方案的身份验证建议。
| 任务 | 示例提示 |
|---|---|
| 为后台服务选择身份验证 | Which authentication method should I use for a background Azure Function that needs to access Azure DevOps APIs? |
| 比较身份验证选项 | Help me choose between service principals, managed identities, and personal access tokens for my Azure DevOps integration |
| Web 应用的身份验证 | I'm building a React web app that needs to access Azure DevOps on behalf of signed-in users — what authentication approach should I use? |
| 从 PAT 迁移 | Help me plan a migration from personal access tokens to Microsoft Entra ID authentication for my Azure DevOps integrations |
| CI/CD 身份验证 | What's the most secure way to authenticate Azure DevOps REST API calls from a GitHub Actions workflow? |
| 排查身份验证失败问题 | I'm getting 401 errors when calling the Azure DevOps REST API with my token — help me diagnose the issue |
注释
代理模式和 MCP 服务器使用自然语言，因此你可以调整这些提示或提出后续问题来优化结果。
相关内容
- 适用于 Azure DevOps 的 OAuth 2.0
- Azure DevOps服务 REST API 参考
- Azure DevOps 中的安全性和标识
- Azure DevOps数据保护概述
- 访问 Azure DevOps 使用 Entra 工作负荷标识