微服务架构下inter-service call的permission handling方案咨询

核心逻辑 #

要实现该需求首先要解决请求来源可信识别的问题，只要能100%判定请求是内部服务间调用还是外部客户端发起，后续的权限校验开关逻辑即可低成本实现。

主流可行方案 #

• 方案一：网关请求头标记+内网访问限制（生产最常用，落地成本低）
  实现步骤：

  1. 所有外部客户端请求必须统一经过API网关，网关转发请求到下游业务服务时，强制覆盖添加X-Request-Source: external请求头，直接丢弃外部请求自带的同名字段，避免伪造。
  2. 内部服务调用框架（HTTP/RPC）做全局统一封装，调用时自动注入X-Request-Source: internal请求头，无需业务开发手动处理。
  3. 所有业务服务的权限拦截器新增如下判断逻辑：

     # 伪代码示例
     req_source = request.headers.get("X-Request-Source", "")
     if req_source == "internal":
         # 内部服务调用，跳过权限校验
         return
     # 外部请求，执行原有权限校验逻辑
     run_origin_permission_check()
     

  4. 网络层做兜底限制：所有业务服务只允许内网IP段访问，禁止公网直接调用，彻底避免外部绕过网关伪造内部请求的风险。

• 方案二：服务身份凭证校验（安全性最高，适合敏感业务场景）
  实现步骤：

  1. 给每个内部服务发放唯一的身份凭证，支持JWT令牌、共享密钥、TLS服务证书三种主流形式。
  2. 内部服务发起调用时，必须在请求头中携带自身的有效服务凭证。
  3. 权限拦截器先校验请求携带的服务凭证合法性，校验通过判定为内部服务调用，直接跳过权限校验；校验不通过则判定为外部请求，执行常规的用户权限校验逻辑。

• 方案三：通信协议/端口区分（成本最低，适合架构分层清晰的场景）
  如果你的架构中内部服务调用统一用RPC协议（如gRPC/Dubbo），外部请求统一走HTTP协议到网关，可直接通过请求协议/端口区分：

  1. 所有RPC端口接收的请求默认判定为内部服务调用，直接跳过权限校验。
  2. 所有HTTP端口接收的请求默认判定为外部请求，执行正常权限校验。

生产落地注意事项 #

1. 所有内部请求相关的标记逻辑必须在框架层统一处理，禁止业务开发手动传递相关请求头/凭证，避免遗漏导致权限逻辑错乱。
2. 上线前要做全链路的绕过测试，验证是否存在外部伪造内部请求的漏洞。
3. 可以搭配灰度发布策略，先对非核心业务放开该逻辑，验证无问题后全量推广。

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