使用Azure DevOps授权Bearer Token克隆仓库报错，求原因及解决步骤

问题背景 #

我尝试使用Azure服务连接生成的Bearer Token克隆Git仓库，该服务主体已具备目标仓库的读取权限。已为AAD应用配置了API权限（不确定是否必要，问题仍未解决），并执行了以下操作：

• 设置默认组织和项目：az devops configure --defaults organization="$org" project="$project"（$org为Azure DevOps组织，$project为仓库所在项目）
• 获取访问令牌：$token = az account get-access-token --resource "499b84ac-1321-427f-aa17-267ca6975798" --query "accessToken" --output tsv
• 配置Git额外请求头：git config --local http.<repo base URL>.extraheader "AUTHORIZATION bearer: $token"

以上步骤通过AzureCLI@2任务在PowerShell脚本中执行，但运行git clone时出现错误：

error: failed to execute prompt script (exit code 1)
fatal: could not read Username for '': No such file or directory

错误原因分析 #

1. Git配置时机错误：使用--local参数配置Git时，只会修改当前目录下的.git/config文件，但克隆操作前本地不存在该仓库目录，配置根本没有生效，导致Git仍尝试触发身份验证流程。
2. Bearer Token格式不规范：Git要求Authorization头的格式为Bearer <token>（Bearer首字母大写，冒号后无空格），你写的bearer: $token格式不符合HTTP授权头规范，授权失败后Git会自动弹出用户名密码提示，最终因无法读取输入报错。
3. 服务主体身份上下文错误：az account get-access-token获取的是当前Azure CLI登录账户的令牌，如果AzureCLI@2任务未以目标服务主体身份登录，拿到的令牌不属于具备仓库权限的服务主体，自然无法通过授权，触发身份验证提示。

解决步骤 #

1. 确保Azure CLI以服务主体身份登录 #

在AzureCLI@2任务中，先通过服务连接完成身份验证：

az login --service-principal -u $servicePrincipalId -p $servicePrincipalSecret --tenant $tenantId

（$servicePrincipalId、$servicePrincipalSecret、$tenantId可从Azure服务连接的参数中获取）

2. 获取并格式化正确的访问令牌 #

保持Azure DevOps资源ID499b84ac-1321-427f-aa17-267ca6975798不变，生成符合规范的授权头：

$token = az account get-access-token --resource "499b84ac-1321-427f-aa17-267ca6975798" --query "accessToken" --output tsv
$authHeader = "Bearer $token"

3. 克隆时正确传递授权配置 #

方法一：克隆时通过-c参数临时配置（推荐，无需提前创建目录）：

git clone -c http.<repo base URL>.extraheader="AUTHORIZATION: $authHeader" <完整仓库URL>

例如仓库URL为https://dev.azure.com/MyOrg/MyProj/_git/MyRepo，则<repo base URL>填写https://dev.azure.com/MyOrg/MyProj/_git。

方法二：先创建空目录，进入后配置再克隆：

mkdir MyRepo
cd MyRepo
git config --local http.<repo base URL>.extraheader="AUTHORIZATION: $authHeader"
git clone <完整仓库URL> .

4. 权限验证（可选） #

AAD应用配置的Azure DevOps User Impersonation权限是必要的（服务主体需要模拟用户访问DevOps资源），但仓库的读取权限最终以Azure DevOps组织/项目中给服务主体分配的显式角色为准，确保服务主体已被添加到目标仓库的Reader组中。

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