MSAL用户令牌缓存中的ID Token缺失AcquireInteractiveToken返回的自定义声明

核心原因分析 #

静默获取令牌时，MSAL大概率返回的是刷新令牌换取的新ID Token，而非初始交互式登录得到的完整版本。Azure AD B2C默认通过刷新令牌获取ID Token时，不会重新执行自定义策略的全部声明转换流程，导致extension_开头的自定义声明缺失。

具体解决方案 #

1. 确保自定义策略持久化ID Token声明 #

在自定义策略的RelyingParty节点里，必须把extension_声明明确加入OutputClaims，保证令牌刷新时能重新获取这些声明：

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <!-- 新增你的自定义扩展声明 -->
      <OutputClaim ClaimTypeReferenceId="extension_userRole" />
      <OutputClaim ClaimTypeReferenceId="extension_customTag" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

同时检查ClaimsSchema中的声明定义，确保extension_声明的DataType和属性配置正确，且在用户旅程的对应步骤中已被收集或读取。

2. 强制静默请求刷新完整ID Token #

调用AcquireTokenSilent时添加WithForceRefresh(true)参数，强制MSAL用刷新令牌向Azure AD B2C请求全新ID Token，而非直接返回缓存的精简版本：

var result = await _pca.AcquireTokenSilent(scopes, accounts.FirstOrDefault())
    .WithForceRefresh(true)
    .ExecuteAsync();

注意：频繁强制刷新会影响性能，建议仅在需要最新自定义声明时使用，或结合令牌生命周期设置合理的触发时机。

3. 检查令牌缓存的序列化逻辑 #

如果自定义了令牌缓存的序列化（比如用文件/数据库存储），要确保序列化、反序列化过程中没有丢失ID Token的完整声明。比如验证TokenCache中的IdToken属性是否被完整保存和读取，避免只存储了令牌的部分数据。

4. 确认作用域与协议配置完整性 #

虽然已设置openid和offline_access，但要检查自定义策略中OpenIdConnect协议的Scope配置是否包含这两个作用域：

<Protocol Name="OpenIdConnect">
  <OutputTokenFormat>JWT</OutputTokenFormat>
  <Metadata>
    <Item Key="client_id">你的客户端ID</Item>
    <Item Key="response_types">code id_token</Item>
    <Item Key="scope">openid offline_access</Item>
  </Metadata>
</Protocol>

若自定义声明关联了特定API权限，需确保客户端应用已添加对应权限并完成管理员同意。

额外排查步骤 #

• 用jwt.ms分别解析交互式登录和静默获取的ID Token，对比声明差异，确认缺失的具体extension_字段。
• 查看Azure AD B2C的监控日志（门户「监控」->「日志」），检查静默请求的响应细节，看是否存在声明过滤的相关记录。

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