APISIX插件开发之Kong网关HMAC鉴权插件（附客户端SDK）
内容提要
文章介绍将Kong网关的HMAC鉴权插件移植到APISIX。因生产环境大量API沿用Kong HMAC，为减少客户端改造，团队选择Kong较简洁的鉴权方案而非APISIX自带方案。插件由运维开发完成并测试，会将Consumer名称写入X-Client-ID请求头供后端识别来源。文中给出插件Lua代码、启用方法及路由配置示例，并分享各语言客户端SDK方便快速接入。
延伸解读
迁移背景与选型考量
文章指出，团队在生产环境已使用Kong近一年，大量API依赖Kong HMAC鉴权。迁移到APISIX时，为减少客户端改造，选择移植Kong插件而非采用APISIX自带HMAC。作者对比后认为APISIX的HMAC更复杂严格，签名需包含请求方法、Querystring和头部等，而内部API更倾向Kong的简洁方案。这反映了技术选型中兼容性与迁移成本的权衡。
插件行为与后端识别
该插件在鉴权通过后，会将Consumer名称写入请求头X-Client-ID，供后端应用识别来源，便于后续权限分级或日志记录。插件支持hmac-sha1、hmac-sha256、hmac-sha512算法，并可配置clock_skew、signed_headers、validate_body等参数。代码中已处理Authorization头解析和多种签名校验逻辑，并注明经过验证测试。
启用与客户端接入
启用时需将插件代码保存为kong-hmac.lua并放入apisix/plugins目录，然后在config.yaml的plugins列表中添加kong-hmac。路由配置中通过plugins字段启用该插件。作者还提供了各语言客户端SDK（Demo）并分享至GitHub，方便未接触过HMAC的开发者快速调试接入，降低迁移门槛。
Q&A
为什么要把Kong的HMAC鉴权插件移植到APISIX？
因为生产环境已有大量API使用Kong HMAC鉴权，迁移到APISIX时为了减少客户端改造工作，决定移植该插件，并将Kong的HMAC认证作为后续API接口的统一鉴权方案。
APISIX自带的HMAC鉴权和Kong的HMAC鉴权有什么区别？
APISIX的HMAC鉴权更加复杂、严格，客户端签名生成更繁琐，例如signature需要额外包含请求方法、Querystring和头部等；而Kong的方案更简洁。
移植后的插件如何让后端识别请求来源？
插件会将Consumer名称写入请求头X-Client-ID，方便后端应用识别/记录来源，做后续的权限分级等逻辑。
如何在APISIX中启用这个Kong HMAC插件？
将插件代码保存为kong-hmac.lua，拷贝到apisix/plugins目录，然后在config.yaml的plugins列表中添加- kong-hmac即可启用。
这个插件支持哪些HMAC算法？
支持hmac-sha1、hmac-sha256和hmac-sha512三种算法，默认使用hmac-sha256。
有没有客户端SDK可以快速接入Kong HMAC鉴权？
有，作者整理开发了各语言的Kong网关HMAC鉴权SDK（Demo），已分享到GitHub：https://github.com/jagerzhang/hmac-sdk，方便开箱即用。
