OAuth2.0/OpenID Connect客户端对接多资源？及授权相关问题

问题1：管理应用是否需为每个提供方应用注册独立OAuth2.0客户端？还是仅用单个客户端，基于分配的scopes对接所有提供方应用？ #

结论：用单个客户端配合scopes即可，无需为每个提供方注册独立客户端

• 你的内部授权服务器已经基于scopes分配了客户端访问其他应用的权限，管理应用作为单个客户端，只需在授权请求中指定对应提供方的scopes，就能获取访问该提供方数据的合法权限。
• 提供方数量是0到无限的，注册大量客户端会带来极高的维护成本——比如密钥管理、权限配置、客户端生命周期管控，完全没必要做这种重复工作。
• 只要内部授权服务器的权限模型能通过scopes精准区分管理应用对不同提供方的访问范围，单个客户端方案在安全性和效率上都能满足需求。

问题2：计划用JWT中的claims传递租户识别信息是否可行？这是否会影响客户端选型？ #

可行性：完全可行 #

JWT的设计初衷就包含携带自定义业务元数据，租户识别信息属于典型的业务上下文数据，非常适合放在claims中传递：

• 管理应用可以在发起OAuth2.0授权请求时，通过授权服务器支持的扩展参数（比如标准的claims参数，或者内部自定义的请求参数），将组合后的租户信息传递给授权服务器。
• 授权服务器在颁发JWT令牌时，把该租户信息写入到令牌的自定义claims字段中。
• 提供方应用验证JWT的有效性后，直接从claims中提取租户信息即可完成识别。

对客户端选型的影响：无任何影响 #

不管你选择单个客户端还是（不推荐的）多个客户端方案，只要内部授权服务器支持生成带自定义claims的JWT，这个方案都能正常运行。
反而单个客户端方案更适配这种动态传递租户信息的场景——你不需要为不同租户或提供方维护不同的客户端配置，只需在每次授权请求中动态组装租户信息即可，灵活性更高。

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