Entra ID：通过客户端凭证流为令牌添加actor声明

核心结论 #

客户端凭证流（服务主体/托管标识）下，Entra ID不支持通过TokenRequestContext的claims参数直接添加自定义声明（如actor）。这个参数的设计目标是针对用户参与的认证流程（如授权码流、ROPC流），用来请求用户相关的额外声明，纯服务到服务的调用场景中会被直接忽略。

为什么你的代码中claims参数无效？ #

你提供的代码里，虽然通过TokenRequestContext传递了claims参数：

var claimsDict = new Dictionary<string, string>
{
    { "actor", "john.doe@example.com" }
};
var context = new TokenRequestContext(scopes: new[] { scope }, claims: JsonConvert.SerializeObject(claimsDict));
var accessToken = await azureCredential.GetTokenAsync(context);

但Entra ID的客户端凭证流端点不会处理这个参数——该参数仅在用户作为认证主体的流程中生效，用来请求用户的属性或额外声明，服务主体身份的请求会直接跳过这部分逻辑。

可行解决方案 #

如果要把Membership用户名嵌入JWT令牌或安全传递，有以下几种合规方式：

1. 静态自定义声明映射（适合固定身份场景） #

为服务主体配置Entra ID内置的自定义声明：

• 登录Entra ID门户，找到你的服务主体（托管标识对应的服务主体在"托管标识"菜单下关联查看）
• 进入令牌配置 → 添加可选声明，选择actor或其他合适的声明类型
• 配置完成后，服务主体获取的令牌会包含该声明，但值是静态的，无法动态传入不同的Membership用户名

2. 动态自定义令牌签署（适合动态用户场景） #

如果需要为每个请求传递不同的用户名，可采用双层令牌方案：

• 应用服务器先通过客户端凭证流获取Entra ID颁发的服务主体令牌（验证服务身份）
• 应用服务器使用自有密钥/证书签署一个包含actor声明的JWT，将Entra ID令牌作为assertion字段嵌入其中
• API端先验证Entra ID令牌的有效性（确认服务主体权限），再验证自定义JWT的签名，提取actor声明

3. 优化后的HTTP头方案（简单易实现） #

你的备选方案可以优化得更安全：

• 为服务主体添加自定义应用角色（如CanImpersonateUser）
• API端先检查令牌的roles声明是否包含该角色，仅当存在时才信任自定义HTTP头（如X-Impersonated-User）中的用户名
• 这种方式符合Entra ID的权限模型，实现成本低，是服务到服务 impersonation场景的常用方案

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