客户端凭证流下API间调用能否限制对目标API的部分访问权限

核心结论 #

客户端凭证流完全支持仅授予API1访问API2部分接口的权限，你当前的服务账号权限模型可以无缝迁移到客户端凭证流的实现逻辑中，无需更换其他授权流。 #

两种常见的权限控制实现方式 #

你认为ApiScopes不适用于该场景，大概率是默认将scope等同于「整个API的访问权限」，实际上你可以根据你的权限粒度选择更适配的方案：

• 细粒度Scope方案：在API2侧定义和接口/接口组绑定的自定义scope，比如api2:order:query、api2:user:modify，在身份提供商侧给API1对应的客户端仅授权所需的scope，access_token签发时会携带已授权的scope列表，API2侧收到请求后校验当前接口要求的scope是否在token的scope列表中即可完成鉴权。这种方案适合接口数量少、权限规则简单的场景。
• 客户端角色绑定方案：完全对齐你当前的服务账号实现逻辑，你可以在身份提供商侧为API1对应的客户端ID绑定你现有已经配置好的角色，授权服务签发access_token时将角色信息写入token的自定义声明字段（比如client_roles），API2侧直接复用现有服务账号的鉴权逻辑，解析token中的角色字段匹配接口访问权限即可。这种方案迁移成本极低，完全适配你现有的权限模型，不需要调整权限规则。

适配性说明 #

API到API的无用户参与的服务间调用场景，客户端凭证流是OAuth2规范中最适配的授权流，没有必要更换其他授权方案。如果你当前的权限粒度极细、接口数量多，使用细粒度scope会导致scope数量膨胀难以维护，直接选择上述第二种客户端角色绑定方案即可。

落地时可以将鉴权逻辑统一放在API2的网关层/统一鉴权中间件实现，不需要业务接口单独做权限校验，可复用现有服务账号方案90%以上的鉴权代码。

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