`az account get-access-token --resource api://<appid>` 后台工作原理探究

核心流程：基于用户身份的令牌请求 #

Azure CLI执行az account get-access-token --resource api://<appid>的底层逻辑，是以你当前登录的用户身份，结合自身预授权的客户端身份，直接向Azure AD请求目标API的访问令牌，具体分两种场景：

• 若你通过az login完成交互式登录，CLI会使用缓存的用户授权码或刷新令牌发起请求；
• 若是非交互式登录（如服务主体），则直接使用服务主体的凭据请求令牌。

预授权客户端应用的作用 #

你提到的“Azure CLI被设为预授权客户端应用”是关键：

• 这个设置本质是Azure AD允许指定客户端（此处为Azure CLI，客户端ID04b07795-8ddb-461a-bbee-02f9e1bf7b46）代表用户向目标API请求令牌，无需为CLI单独配置权限范围；
• 这里的权限逻辑是用户委派权限：CLI只是“代理”你（登录用户）发起请求，只要你作为用户本身对目标API有访问权限（比如被分配了API的角色），Azure AD就会颁发令牌——CLI自身不需要对API有应用权限。

为什么不涉及OAuth 2.0 On-Behalf-Of（OBO）流程 #

OBO流程的核心是“中间层API用用户令牌换取下游API令牌”，但此场景中：

• Azure CLI是直接的请求发起者，没有中间层API参与；
• CLI直接以用户身份和自身客户端ID向Azure AD请求目标API的令牌，全程只有终端用户、CLI、Azure AD、目标API四方，完全不满足OBO流程的“三层架构”要求。

具体执行步骤拆解 #

1. CLI读取本地缓存的用户身份凭据（如刷新令牌，来自之前的az login）；
2. 向Azure AD令牌端点发送请求，核心参数包括：

   client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46
   grant_type=refresh_token
   refresh_token=<缓存的用户刷新令牌>
   resource=api://<appid>
   

3. Azure AD验证：
   • CLI的客户端ID是否在目标API的预授权客户端列表中；
   • 当前登录用户的身份有效性，以及用户对目标API的访问权限；
4. 验证通过后，Azure AD返回目标API的访问令牌，CLI将其输出或缓存。

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