如何计算 HMAC 签名

为什么这个工具重要

Webhook 是云服务回调你的方式：Stripe 在支付入账时回调；GitHub 在发布切割时回调。为证明消息真实，发送方用共享密钥对正文计算 HMAC 并放在头里。若校验永远失败，你无法判断是密钥错、算法错，还是正文被代理改过。并列展示的 HMAC 工具配合输入预览，能把调试循环从几小时缩短到几分钟。

三个真实场景

操作演练

打开 HMAC 生成器。

1. 1

   粘贴消息

   即被签名的确切字节 —— 通常是原始 HTTP 正文。注意空白差异。

2. 2

   粘贴密钥

   字符串默认按 UTF-8 解释。若厂商下发二进制密钥，勾选「密钥为 hex」或「密钥为 Base64」。

3. 3

   选择哈希算法

   SHA-256 是现代默认；旧系统仍有 SHA-1；SHA-512 少见但支持。

4. 4

   选择输出格式

   十六进制（小写）最常见于头字段。Base64 用于 AWS Sig V4 等若干 API。

5. 5

   与收到的签名比对

   从头里粘贴签名值；工具会逐字符高亮匹配与否。

Message:  t=1731234567.{"id":"evt_123","type":"payment_intent.succeeded"}
Secret:   whsec_abc123xyz
Algorithm: SHA-256

4ed7a40c1e1f9c0bba9d7c1f24eb44a3f0bd06d0c81bd5d4a7f6cf52a6f00f1e

实用技巧

• 签名前先 diff 正文。 大量 Webhook 失败源于代理在正文末尾多加了一个换行。签名覆盖的是确切字节 —— 最后一个 \n 也算数。
• 服务端务必做常量时间比较。 这是你代码的职责，不是签名工具的。浏览器工具可做明文比对是因为数据不离页。
• 轮换密钥不停服：短时间允许两把密钥都有效。用工具分别算出两把密钥下的签名，确认新密钥无误后再停用旧密钥。
• 把你的规范化字符串写进文档。 AWS Sig V4 等要把方法、路径、头与正文哈希按特定规则拼接；用手工在工具里复算一次可验证公式。

常见陷阱

不适合用本工具的情况

• 公钥签名（RSA、ECDSA、Ed25519） — 需要另一类校验器。参见 如何在线校验数字签名。
• 对称加密 — HMAC 只认证，不加密。若同时要保密与认证，请考虑 AES-GCM。
• 口令存储 — 永远不要用 HMAC 存口令，请用慢 KDF。

常见问题

延伸阅读

1. 若协议要求先 body_hash 再 HMAC，可先用 哈希生成器 单独哈希正文。
2. 构建完整请求签名：参数签名工具。
3. 解码 JWT 片段可借助 编解码工具 —— HS 前缀算法使用 HMAC。