使用v1 Azure AD授权URL的多租户应用添加委托权限后应用权限消失问题

这个现象其实是Azure AD v1授权端点的预期行为，核心原因在于应用权限（Application Permissions）和委托权限（Delegated Permissions）在v1端点下是通过完全不同的认证流程获取的，且不会出现在同一个access_token中。

下面具体拆解原因：

• 两种权限的获取流程完全分离
  应用权限属于「应用自身」的权限，不需要用户上下文，必须通过client credential flow（即使用客户端ID+密钥/证书直接请求token）来获取包含这些权限的token，这类token的roles字段会列出已授权的应用权限。
  而你新增的Directory.AccessAsUser.All是委托权限，属于「用户上下文下的应用权限」，需要通过authorization code flow或implicit flow（带用户交互的流程）来获取token，这类token的scp字段会列出已授权的委托权限。

• Admin Consent的作用范围
  你通过/common/oauth2/authorize端点触发的admin_consent，本质上是针对委托权限的管理员同意操作——它只会确认应用可以代表用户行使这些委托权限，但不会影响已授权的应用权限，也不会让应用权限出现在委托流程获取的token里。之前的应用权限并没有消失，只是你现在获取的token类型不对，所以看不到它们。

• v1端点的token特性
  v1端点不会在同一个access_token中混合应用权限和委托权限：要么是应用权限的token（来自client credential flow），要么是委托权限的token（来自用户交互流程），二者是完全独立的。

解决方案 #

1. 分开获取对应类型的token
   • 如果需要使用应用权限，继续通过client credential flow请求token，你会在roles字段看到之前的所有应用权限。
   • 如果需要使用Directory.AccessAsUser.All委托权限，就通过授权码流程获取token，此时scp字段会包含该权限。
2. 确认应用权限的授权状态
   你可以在Azure AD门户的应用注册页面，进入「API权限」查看应用权限的状态是否为「已授予管理员同意」——如果之前的同意有效，client credential flow获取的token会正常包含这些权限。

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