微服务场景下OAuth2 client_credentials授权类型的服务间调用选型问题

两种令牌模式的本质差异 #

• 透传前端传入的用户访问令牌：本质是代表当前发起请求的终端用户身份向下游发起调用，全链路的权限判断、审计追踪都绑定到该用户的实际权限范围，不会产生身份代持的断层。
• 用client_credentials申请独立服务令牌：本质是代表己方服务自身的机器身份发起调用，令牌不关联任何终端用户信息，权限范围是服务侧预先在授权服务器上配置的固定范围，调用记录只会关联到服务本身，不会追溯到具体操作的自然人。

对应你当前业务场景的选型结论 #

没有非黑即白的标准答案，完全跟着调用的身份归因逻辑选择即可：

优先选择透传用户访问令牌的情况 #

如果当前调用下游创建用户的动作，本身就是当前登录终端用户权限范围内的业务操作——比如是管理员在前端发起的批量用户创建请求，那么直接把前端传入的有效访问令牌透传给下游服务是最合规的选择：

• 权限控制符合最小权限原则：下游服务不需要给己方服务开放过高的机器权限，只需要校验透传令牌里是否携带「创建用户」的对应scope即可，从根源上避免权限放大
• 审计链路完整可追溯：下游服务记录的操作日志会直接关联到真实发起请求的终端用户，后续排查操作异常、核对责任归属时可以形成完整的证据链
• 实现成本极低：基于Spring WebClient的实现不需要额外对接令牌申请逻辑，只需要配置ServletBearerExchangeFilterFunction（响应式栈用ServerBearerTokenExchangeFilterFunction），即可自动把当前请求上下文里的用户令牌透传到下游调用链路。

选择独立client_credentials令牌的情况 #

只有当这次跨服务调用完全脱离当前终端用户的权限边界时，才需要走机器对机器的授权模式：

• 比如己方服务收到前端请求后，需要向下游同步创建服务专属的系统内置账号、或者初始化和当前登录用户无关的全局配置数据，这类操作本身就不属于终端用户的可操作范围
• 或者当前前端传入的令牌权限范围，无法覆盖下游需要的操作权限，但又不能给终端用户开放对应的高权限时，才需要让WebClient配置client_credentials模式，在授权服务器上给己方服务配置刚好覆盖下游「创建用户」操作的最小scope，申请独立令牌发起调用

常见踩坑提醒：别为了省适配令牌的事，不管什么场景都用服务自身的client_credentials令牌代替用户令牌发下游调用。这种做法直接就打破了OAuth2的权限边界：哪怕前端传的用户令牌权限极小，只要经过己方服务的调用环节，就会自动继承服务的全部机器权限，直接形成越权风险。

内容的提问来源于stack exchange，提问作者Peter S.