验签方法

一般来说，为了避免各个业务系统分别实现验签方法，导致系统间对接成本过高、代码冗余重复造轮，增加不必要的工作量，企业一般会统一验签规则。

APISIX 网关验签

APISIX 是一个动态、实时、高性能的API网关，如果想设置对外暴露的接口地址转发至相应的k8s服务，可以在 APISIX 中配置路由，在插件配置步骤中可开启 hmac-auth 验签（此插件可自定义），并实现验签功能。

hmac-auth 验签插件支持自定义请求头及一系列的 filter 规则，支持统一的正确/错误响应体，也支持在 nacos 中读取限流配置信息。自定义好插件后，需要将插件启动，在容器中运行才可生效。

nacos 限流配置

验签密钥

而只要开启了 APISIX 的 hmac-auth 验签，所有经过该路由的方法都需要用这个验签方法，怎么就能让业务系统接入这个验签规则呢？我们公司的 PAAS 系统就在创建应用的时候，为业务系统创建了相应的 APPKEY 和 secret，并且调用了APISIX的一个请求消费者的接口，将APPKEY 和 secret 推给了 APISIX，这才将业务系统的密钥传到了 APISIX 的网关验签，使得业务系统的验签规则可适用于APISIX的网关验签。至于如何使用，PAAS 只需要集成一套适用于APISIX网关的验签方法，做成组件让业务系统接入就可以使用了。

{
  "username": "jr_paas_getway",
  "desc": "paas层网关配置",
  "plugins": {
    "hmac-auth": {
      "access_key": "1937e8e7-5c91-4023-bfc9-38b5d79f12d5",
      "algorithm": "hmac-sha256",
      "clock_skew": 0,
      "disable": false,
      "secret_key": "a6063352-0abf-4697-b6b4-7eab40c88bdd",
      "signed_headers": [
        "appKey"
      ]
    }
  }
}

自定义验签

对于不需要经过网关的接口，即业务系统的接口，需要自定义一套验签方法，一般用于业务系统间对接调用。所以 PAAS 就定义了一套适用于客户端的验签方法。

调用方会在调其他业务系统接口时在请求头中携带相应的 APPKEY 和 secret 生成的签名，被调用方需要在配置文件中配置上调用方携带的 APPKEY 和 secret，然后在接口加上 @SignValidated 注解。

@SignValidated 注解作用：aop 获取请求头中的 APPKEY 和 SIGNATURE，与配置文件中的 APPKEY 和 secret 生成的签名比对，一致则验签通过。

供应商对接

而在对接供应商时开放给外网的接口，一般会接入供应商提供的验签方法。

而公司也有一个被外网调用的URL，统一按照/paas/v1/callback/业务模块/**/**提供给供应商，并在APISIX做好路由转发到相应的业务模块。

IP白名单

有些供应商会提供IP给到我们，可以让公司运维为暴露到外网的接口配置IP白名单，仅允许该厂商调用。

厂商定义验签

有些供应商也会制定一套验签规则，需要在对接过程中约定好传输的appKey和secret及验签方式。在项目中定义适用于该厂商的 @SignValidated 注解，并写一个aop切面用于处理该厂商的验签方法。

对接过程中需要与厂商多次联调测试，以确保加上验签后能成功解密出厂商传输到业务系统接口的数据。

注意要点

公司目前有两套验签方式，需注意这两者的区别和使用场景，在进行对接时需提前沟通好使用哪种验签方式。

使用网关验签时，

被调用方：需在 APISIX 开启 hmac-auth 验签

调用方：需使用 paas 的生成网关验签请求头方法。

使用自定义验签时，

被调用方：1. 配置文件添加 appKey 和 secret 配置 2. 在接口加上 @SignValidated 注解

调用方：使用 paas 的自定义生成验签请求头方法

如果使用自定义验签时仍不生效，在检查配置正确、依赖正确、方法正确后，可以再在 APISIX 上检查该接口是否配置了路由转发，导致自定义验签获取不到真正的接口地址从而导致验签失败，也有在 APISIX 同时开启了网关验签而与自定义验签冲突的可能性。