IdentityServer4的/connect/userinfo端点会返回哪些映射claims？

文档中提及的「映射后的claims」到底指什么 #

别把这个映射想得太复杂，这里根本不是指从数据库读取用户claim的过程，本质是两层筛选处理后的结果：

• 基础准入规则：当前请求携带的access_token必须至少包含openid scope，否则端点直接返回401，不会返回任何用户信息。所有允许返回的claim范围，完全由这个token里携带的已授权scope决定。
• 核心筛选逻辑：每一个被scope引用的身份资源（也就是IdentityResource，包含openid、profile、email这类系统内置资源，和你自己配置的自定义身份资源），注册时都会显式声明本资源允许承载哪些claim类型。只有被归到这些已授权资源下的claim，才会经过标准化格式处理（比如长格式ClaimType转OpenID标准短名称、剔除不符合资源要求的无效字段），最终作为响应返回。这个“资源绑定筛选+格式标准化”的流程，就是文档里提到的“映射”。

为什么你在AspNetUserClaims中配置的claim没有被返回 #

这类问题基本都是配置链路没打通导致的，常见的漏项有这几个：

• 自定义claim没有绑定到任何身份资源。很多人习惯直接在AspNetUserClaims表里加自定义字段，但没有在IdentityServer配置中，把这个claim的类型名加到对应IdentityResource的ClaimTypes集合里。这种情况下IdentityServer在做响应筛选时会直接把这类无归属的claim过滤掉，根本不会进入返回范围。
• 对应身份资源没有完成全链路授权。就算你把claim加到了某个自定义IdentityResource的配置里，如果这个资源对应的scope没有被包含在客户端允许的scope列表里，实际请求token时也没有携带这个scope，那对应的claim自然不会被返回。举个实际场景：你自定义了一个对应员工信息的IdentityResource，绑定了employee_id、department两个claim类型，对应的scope叫employee.info，但你请求token时只带了openid profile，哪怕用户身上存了这两个claim，userinfo端点也不会返回。
• Claim类型名称不匹配。IdentityServer内置了一套标准claim类型的映射规则，会把长格式的ClaimType（比如http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress）自动转换为OpenID Connect标准的短名称（比如email）。如果你自定义的claim没有匹配上这套规则，也没有在资源配置中显式声明对应的类型名，就会被过滤掉。
• 认知混淆：很多人以为userinfo端点是拉取用户的所有存储claim无差别返回，实际上这个端点的返回逻辑和ID Token的生成逻辑完全一致：只返回本次授权范围内、符合资源配置要求的claim，不会无条件返回用户在AspNetUserClaims表中的所有内容。

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