配置的额外Profile Claim（spn）未同步至客户端应用的问题排查

我之前在Identity Server + ASP.NET Identity的组合中也碰到过类似的自定义Claim不生效的情况，给你几个实用的排查方向：

• 确认Profile身份资源的Claim配置是否正确
  你需要确保在定义Profile资源时，明确把"spn"添加到它的UserClaims集合里，而且要注意Claim名称是区分大小写的。比如：

  services.AddIdentityServer()
      .AddInMemoryIdentityResources(new List<IdentityResource>
      {
          new IdentityResources.OpenId(),
          new IdentityResources.Profile()
          {
              UserClaims = { "spn" } // 这里必须显式添加自定义Claim
          }
      })
      // 其他配置...
  

  如果用EF存储配置，还要确保这个配置已经同步到数据库的IdentityResources表中，检查UserClaims字段是否包含"spn"。

• 验证用户Claims集合中确实存在"spn"
  即使你在数据库的AspNetUserClaims里加了记录，也要确认在Profile服务中能拿到这个Claim。可以在自定义Profile服务里加个调试点，看看context.Subject.Claims里有没有"spn"：

  public async Task GetProfileDataAsync(ProfileDataRequestContext context)
  {
      // 这里打个断点，检查Claims集合
      var userClaims = context.Subject.Claims.ToList();
      // 可以临时把所有Claims输出到日志，确认spn是否存在
      foreach (var claim in userClaims)
      {
          Console.WriteLine($"{claim.Type}: {claim.Value}");
      }
      context.IssuedClaims = userClaims;
  }
  

  如果这里拿不到，那问题出在ASP.NET Identity的Claim存储或者用户认证环节，和Identity Server无关。

• 检查客户端是否请求了"profile" Scope
  只有当客户端在请求令牌时包含了"profile" Scope，Profile资源里的Claim才会被包含到身份令牌中。要确保：

  1. 客户端配置的AllowedScopes包含"profile"；
  2. 令牌请求的scope参数里明确带上了"profile"（比如openid profile）。

• 排查是否存在Claim过滤或映射规则
  Identity Server默认不会过滤自定义Claim，但如果你配置了自定义的IClaimsFilter或者修改了ClaimTypeMapping，可能会影响spn的输出：

  • 检查IdentityServerOptions里有没有设置ClaimsProvider或自定义过滤器；
  • 确认没有把"spn"映射成其他不存在的类型，比如：

    services.Configure<IdentityServerOptions>(options =>
    {
        // 确保没有这类映射把spn覆盖掉
        options.ClaimTypeMapping.Remove("spn");
    });
    

• 确认身份令牌的类型和受众
  有些场景下，自定义Claim只会出现在ID Token中，而不会出现在Access Token里（如果是API请求的话）。你要确认自己检查的是正确的令牌类型，而且客户端的AllowedGrantTypes和令牌用途匹配。

按照这个顺序排查，应该能找到问题所在。

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