使用服务主体替代普通用户配置仅支持PAT的服务连接

一、针对微软系服务（如Azure Repos）：使用Service Principal的OAuth身份验证 #

• 直接跳过PAT，利用Azure AD OAuth 2.0完成身份验证：
  1. 在Azure DevOps创建服务连接时，选择对应服务类型（比如「Azure Repos Git」）。
  2. 身份验证方式选择「Azure Active Directory」，关联已配置好的Service Principal。
  3. 在Azure DevOps项目中，给该Service Principal分配所需的最小权限（如代码读取、贡献者等）。
  4. 配置完成后，服务连接会自动使用SP的OAuth令牌访问服务，无需手动生成PAT。

二、第三方服务（如SonarCloud）：适配服务支持的身份验证方式 #

• 如果服务支持Azure AD集成：
  1. 在第三方服务的组织/项目设置中，添加Azure AD应用关联，将Service Principal配置为服务账户。
  2. 生成该服务专属的访问令牌（非PAT），并在Azure DevOps服务连接中使用此令牌完成认证。
• 如果服务仅支持用户级PAT：
  1. 创建一个专用的Entra ID服务用户（仅用于服务场景的普通用户，非个人用户）。
  2. 给该服务用户分配第三方服务和Azure DevOps项目的必要权限。
  3. 用此服务用户生成PAT，替代原项目管理员的PAT使用。这种方式避免了个人用户离职、权限变更带来的影响，且可以严格控制权限范围。

三、使用Azure DevOps托管标识 #

• 若使用Azure DevOps云代理或自托管代理，可启用托管标识来替代PAT：
  1. 为代理配置系统分配或用户分配的托管标识。
  2. 在Azure AD中，给该托管标识授予Azure DevOps项目的对应权限。
  3. 在管道任务中，使用托管标识进行身份验证，直接访问支持Azure AD认证的服务，无需PAT。

关键注意事项 #

• 权限最小化原则：无论采用哪种方案，都要给服务账户/SP/托管标识分配刚好满足业务需求的权限，避免过度授权。
• 凭据生命周期管理：对于专用服务用户的PAT，设置合理的过期时间并定期轮换；所有敏感凭据建议存储在Azure Key Vault中，通过管道引用而非硬编码。

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