Blazor向API传递认证时丢失部分Claims的问题排查

Blazor Server与WebAPI中用户Claims差异大的核心原因是两者的用户主体Claims来源完全不同，即使使用同一授权服务器，生成逻辑和受众也有区别，具体分以下几点：

1. Claims的来源渠道不同 #

• Blazor Server的IHttpContextAccessor获取的用户主体，是OpenID Connect认证完成后写入Cookie的ClaimsPrincipal，其Claims来自两个地方：
  • 授权服务器返回的ID Token中的Claims
  • 通过UserInfoEndpoint接口拉取的额外用户Claims（因为你配置了GetClaimsFromUserInfoEndpoint = true）
• WebAPI的用户主体，是直接解析请求头中的Access Token生成的，Access Token是授权服务器专门为API受众（Audience）生成的，通常仅包含API业务所需的必要Claims，不会像ID Token/UserInfo那样返回全量用户信息。

2. Token的受众（Audience）配置差异 #

OpenID Connect中，不同客户端/资源对应的Token受众不同：

• Blazor作为客户端，获取的Access Token默认受众是授权服务器自身或Blazor的客户端ID
• WebAPI作为受保护资源，JWT Bearer中间件默认会验证Token的受众是否匹配API的标识（如API的ClientId）
  授权服务器会针对不同受众生成不同内容的Token，这直接导致解析后的Claims集合存在差异。

3. Claims映射与处理逻辑不同 #

• Blazor的OpenID Connect配置中，你显式设置了TokenValidationParameters的NameClaimType和RoleClaimType，同时Cookie认证中间件可能会对Claims做额外的转换、过滤；
• WebAPI的JWT Bearer配置使用默认规则，Claims映射遵循JWT标准字段（比如默认name会被映射为http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name），如果不手动配置映射，会出现Claim类型名称不一致的“差异”。

4. SaveTokens的作用误区 #

Blazor中SaveTokens = true仅用于将Access Token存储在Cookie中供后续调用API使用，但Blazor自身的用户主体Claims不是从Access Token解析而来，而是来自ID Token和UserInfo接口，所以和API解析Access Token得到的Claims没有直接关联。

1. 统一Claims映射规则：在WebAPI的JWT Bearer配置中添加和Blazor一致的TokenValidationParameters，确保Claim类型名称统一：

   services.AddAuthentication("Bearer")
       .AddJwtBearer("Bearer", options =>
       {
           options.Authority = configuration["Security:Authority"];
           options.TokenValidationParameters = new TokenValidationParameters
           {
               NameClaimType = "name",
               RoleClaimType = "role"
           };
       });
   

2. 调整授权服务器配置：如果需要API获取和Blazor一致的Claims，在授权服务器中为API的资源配置添加所需的Claims（比如将profile、email等Scope包含到API的Access Token中）。
3. 验证Access Token内容：可以使用JWT解析工具查看Access Token的实际Claims，确认是否包含所需字段，排查授权服务器的Token生成逻辑。

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