返回
创建于
状态
公开

下面给你一张「够用且靠谱」的对比速查表,涵盖常见 JWT 签名算法在性能、体积、部署难度上的差异。你用 JWT_ALGO 选型时,基本按这个来就行。

性能&特性对比(概览)

算法签名速度验证速度典型签名长度(Base64URL后)密钥/部署兼容性适用场景
HS256 (HMAC-SHA256)🟢 最快🟢 最快43 字符(32B)只需共享 secret(对称)→ 密钥分发要小心广泛内网/同域服务高 QPS;简单、成本低
RS256 (RSA-2048 + SHA256)🟡 慢(相对)🟢 较快342 字符(256B)私钥签名、公钥验证,易做密钥分发与轮换最通用/标准第三方/多方验证;网关/开放平台
RS512 (RSA-2048 + SHA512)🟡≈RS256,略慢🟢≈RS256,略慢342 字符同 RS256略差(部分老实现只测 RS256)很少有必要(哈希改 256→512 对安全提升不明显)
ES256 (ECDSA-P256 + SHA256)🟢 较快🟡 较慢(相对 RSA)~96 字符(~64–72B DER 编码)非对称;密钥小,便于移动端/硬件好(少数旧库兼容坑)追求小体积(带宽/存储敏感)、移动端/IoT

常见性能排序(CPU 无专门硬件加速,Go/OpenSSL 等主流实现下) 吞吐/延迟:HS256 ≫ ES256(sign 更快 / verify 更慢) ≈ RS256(sign 慢 / verify 快)

  • RSA:签名 、验证 (e=65537)
  • ECDSA:签名 、验证 (相对 RSA)
  • HMAC:对称 MAC,签名/验证都非常快

选型建议(结合你的场景)

  • 内网微服务 / 极高 QPS / 简单可靠:优先 HS256。 缺点是需要在签发方与验证方安全地共享同一个 secret(可用 KMS/密钥注入+短周期轮换缓解)。
  • 对外/多方验证(开放平台、前后端/第三方都要验):优先 RS256。 私钥仅在签发端;下发公钥或 JWKS,便于轮换权限隔离。生态与文档最佳。
  • 带宽/存储敏感(例如 cookie、Header、移动/IoT)、或更小密钥:可选 ES256。 签名更小、签名速度快,但验证偏慢、历史兼容偶有坑;确保你的库/网关稳定支持。
  • RS512:通常不需要。相较 RS256 提升有限,反而增加计算与兼容成本。提高 RSA 密钥位数更实际(如 3072/4096),但也会显著变慢和变大。

大致延迟区间(仅供估算,单核、常见 x86,无硬件加速)

  • HS256:约 < 0.05 ms/op(签名/验证都极快)
  • RS256(2048位)签名 ~0.5–1.5 ms验证 ~0.1–0.4 ms
  • ES256(P-256)签名 ~0.2–0.6 ms验证 ~0.4–1.0 ms

实际取决于语言/库版本、是否开启 AVX/硬件加速、密钥长度、是否启用 JIT/汇编优化、以及你的运行环境(容器/虚拟化/能耗模式)。

体积影响(JWT 总长度)

  • 头/载荷一样时,主要差在签名段

    • HS256:~43 字符
    • ES256:~96 字符(DER 可变)
    • RS256/RS512(2048位):~342 字符
  • 这直接影响 HTTP Header 体积、Cookie 大小与传输/存储成本

Go 实战基准(可直接跑)

go

小结(怎么选)

  • 追求极致性能/QPSHS256
  • 需要非对称、跨服务/第三方RS256(首选,生态最佳)
  • 需要更小签名/移动端友好ES256(注意验证成本与兼容性)
  • 避免RS512(除非有合规或明确要求)

如果你把 JWT_ALGO 做成可切换(例如 HS256 / RS256 / ES256),建议同时支持:

  • kid + JWKS(便于密钥轮换
  • 短有效期 + 刷新机制(降低密钥泄漏风险)
  • 针对 ES256 提前做兼容性验收(网关/SDK/第三方)