HS256 与 RS256：对称式和非对称式 JWT

JWT 签名使用对称算法（HMAC）或非对称算法（RSA、ECDSA）。HS256 = HMAC-SHA256。RS256 = RSA-PKCS1v1.5-SHA256。ES256 = ECDSA-P256-SHA256。选择哪种算法会影响密钥分发方式和信任模型。

HS256 使用一个共享的密钥同时进行签名和验证。颁发方和每个验证方都必须持有同一个密钥。它实现简单，但需要将密钥安全地分发给所有验证方。

当颁发方和验证方是同一个服务时，HS256 很合适（例如，单体 API 为自己的令牌签名并进行验证）。如果多个独立服务需要验证令牌，绝不要使用 HS256，因为它们都必须获得该密钥。

RS256 使用私钥进行签名，使用公钥进行验证。只有身份验证服务器持有私钥。所有资源服务器都从 JWKS 端点获取公钥，并在本地完成验证，无需共享秘密。

RS256 非常适合微服务架构：身份提供商为令牌签名；每个下游服务使用公钥进行验证，而无需针对每个请求联系 IDP。这样可以水平扩展，同时避免密钥分发风险。

ES256 使用基于 P-256 的 ECDSA。对于 2048 位密钥，签名大小为 64 字节，而 RS256 为 256 字节。验证速度约为 RS256 的 10 倍。当带宽或验证速度非常重要时（例如移动 API、IoT），优先考虑 ES256。

对于 RS256/ES256：通过将新密钥（新的 kid）发布到 JWKS 来轮换密钥，使用新密钥为新令牌签名，留出宽限期让旧令牌过期，然后移除旧密钥。HMAC 轮换需要重新分发新的密钥。

HS256 验证：约 1 µs。RS256 验证：约 100 µs（2048 位）。ES256 验证：约 50 µs（P-256）。HS256 速度最快，但需要共享密钥。对于分布式系统，ES256 在安全性和性能之间取得了最佳平衡。

一种严重漏洞：如果验证器盲目信任 alg 标头，攻击者就可以将 alg 从 RS256 改为 HS256，并将服务器的公钥（公开可得）作为 HMAC 密钥来签署令牌。修复方法：绝不要信任 alg 标头。

选择建议：单服务 → HS256。多服务或微服务 → RS256 或 ES256。高吞吐量移动端 → ES256。如果无法确定，请使用 ES256（P-256）或采用 2048 位以上密钥的 RS256。对于对性能敏感的路径，绝不要使用 RS512。

请使用 PyJWT（Python）、jose（Node.js）或 auth0/java-jwt。在验证调用中始终固定预期算法：jwt.decode(token, secret, algorithms=["HS256"])。绝不要传入 algorithms=None，也不要省略该参数。

为什么在微服务架构中更倾向于使用 RS256，而不是 HS256？

HS256 是对称算法（共享密钥）；RS256/ES256 是非对称算法（使用私钥签名，使用公钥验证）。多方系统应使用非对称算法。下一步：利用 JWT 漏洞。