IdentityServer4下OpenID Connect Web API Scopes使用问题咨询

1. 前端统一请求全部scopes的做法是否正确？ #

是正确的。你当前是第一方内部应用，前端本身无法提前感知登录用户的权限范围，统一请求所有业务需要的scope是合理方案，无需额外提前查询用户权限再动态拼接scope参数，反而会增加不必要的交互逻辑，加上你不需要展示授权同意页，这个做法完全没有问题。

2. 是否需要编写自定义逻辑，在access_token生成时仅写入用户有权限的scope？ #

是必须要做的。IdentityServer4默认的发放逻辑只会校验客户端是否有权限申请对应的scope，只要客户端配置允许申请这些scope，就会把用户请求的所有scope全部放到access_token里，不会感知用户本身的权限范围，所以必须加自定义过滤逻辑，否则所有用户拿到的token都会包含全部scope，你的权限划分规则就失效了。

3. 自定义逻辑需要实现哪个接口？是否是IProfileService？是否需要通过角色等用户属性判定？ #

你需要实现的就是IProfileService接口，重写其中的GetProfileDataAsync方法即可。
这个方法会在生成id_token、access_token以及调用用户信息端点时触发，你可以在方法内获取到当前请求的scope列表，再结合当前用户的角色/自定义权限配置（比如给用户关联允许访问的API权限集），过滤出用户实际拥有的scope后写入返回的Claim集合即可。
用角色做判断是非常通用且简单的方案，比如你可以创建ApiAUser、ApiBUser两个角色，分别给X、Y、Z分配对应角色，在过滤scope时直接判断用户所属角色返回对应的A/B类读写scope即可，也可以根据你的业务做更细粒度的权限关联表来判断，都可以。

4. Web API的scope本质上就是权限，这个理解是否正确？ #

在你的业务场景下这个理解完全正确。
OpenID Connect标准中scope的原始定义是资源访问范围，落到Web API的访问控制场景中，scope就是用来限制调用方可以访问API的哪些接口、哪些操作的粒度单位，你把它当作用户访问API的权限标识来用完全符合设计规范。

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