使用AD访问令牌调用Azure DevOps PAT管理API认证失败原因及替代方案

一、认证失败的原因 #

• 缺少用户上下文：你用客户端凭证模式（ClientSecret）获取的Azure AD令牌属于应用自身身份，而PAT是绑定到特定用户的资源，PAT生命周期API要求令牌必须代表具体用户（委托权限需要用户上下文），应用身份无法操作用户的PAT，因此会被重定向到登录页面要求用户身份验证。
• 未指定正确的API Scope：获取令牌时未指定Azure DevOps PAT管理API对应的Scope，导致令牌的受众（aud）和权限不符合API要求，正确的Scope应为https://vssps.dev.azure.com/user_impersonation。
• 权限未完成管理员同意：如果是企业环境下的Azure AD应用，仅配置委托权限user_impersonation还不够，需要全局管理员对该权限授予组织级同意，否则普通用户的权限同意无法生效。

二、修复认证问题的代码调整 #

要获取带用户上下文的令牌，推荐使用设备代码流（适合无人值守流水线场景），首次运行需手动完成一次认证，后续可通过刷新令牌自动维持会话：

$connectionDetails = @{
    TenantId     = '$tenant_id'
    ClientId     = 'client_id'
    Scope        = 'https://vssps.dev.azure.com/user_impersonation offline_access'
    DeviceCode   = $true
}
# 首次运行需在浏览器输入提示的代码完成认证，后续会自动使用缓存的刷新令牌
$token = Get-MsalToken @connectionDetails

$authHeader = @{
    'Authorization' = $token.CreateAuthorizationHeader()
}

Invoke-RestMethod -Headers $authHeader -Uri "https://vssps.dev.azure.com/$organization/_apis/Tokens/Pats?api-version=6.1-preview"

说明：添加offline_access Scope可获取刷新令牌，实现长期无人值守的令牌自动刷新。

三、自动化PAT续期的替代方案 #

1. 改用Azure AD OAuth令牌替代PAT #

如果你的流水线操作支持Azure AD认证，直接使用Azure AD OAuth令牌代替PAT，彻底避免续期问题：

• 服务主体模式：为Azure AD应用分配Azure DevOps组织/项目的对应权限，用客户端凭证模式获取令牌，可长期自动刷新。
• 用户上下文模式：通过设备代码流+刷新令牌维持用户身份，无需手动管理PAT。

2. 使用Azure DevOps内置服务连接 #

在Azure DevOps流水线中配置对应类型的服务连接（如Azure Resource Manager、Azure DevOps服务连接），利用平台内置的认证机制，无需手动维护令牌或PAT。

3. 启用PAT自动续期（有限场景） #

如果是手动创建的PAT，可在创建时启用自动续期功能，但该功能依赖用户账号的活跃状态，自动化场景下可靠性较低，仅适合非核心流水线使用。

内容的提问来源于stack exchange，提问作者Rashmi Wijesooriya