JWT 签名生成器

签名是用密钥对 Header + Payload 计算摘要，生成完整的 JWT 字符串（三段式 header.payload.signature）， 用于服务端向客户端颁发令牌；解码是反向操作，把已有的 JWT 字符串拆开还原 Header/Payload 内容， 但不验证签名真实性。本工具负责签发，配套的 JWT 解码工具 负责解析。 典型流程：① 服务端用本工具（或后端库）签发 JWT；② 客户端携带 JWT 访问 API；③ 服务端用密钥重新计算签名并比对（验签）； ④ 调试时用解码工具查看令牌内容。注意：解码工具无法验签，因为它不持有密钥。

两者都是 JWT 标准算法，差异在密钥模型与适用场景：
- HS256（HMAC + SHA-256）：对称密钥，签发与验签用同一密钥。 性能高、实现简单、token 较短，适合单方服务（如内部系统、单体应用）。 缺点是密钥需在签发方与验签方之间安全共享，泄露后可任意伪造。
- RS256（RSASSA-PKCS1-v1_5 + SHA-256）：非对称密钥， 私钥签发、公钥验签。适合多方协作（如 OAuth2、SAML、微服务架构）， 公钥可公开分发（如 /jwks.json 端点），验签方无需私钥。缺点是 RSA 密钥较长、token 较大、计算稍慢。
选择建议：内部系统用 HS256；对外 API、第三方接入用 RS256；对密钥长度与 token 体积敏感的移动/物联网场景用 ES256（详见下方 ECDSA 专条）。

RFC 7518 建议 HMAC 密钥长度至少等于哈希输出长度：HS256 ≥ 256 位（32 字节）、 HS384 ≥ 384 位（48 字节）、HS512 ≥ 512 位（64 字节）。本工具在密钥长度不足时显示橙色警告， 但仍允许签发（由用户决定）。短密钥的风险：暴力破解——攻击者截获 JWT 后可离线穷举密钥， 若密钥是 "secret"、"123456" 等弱密钥，几分钟即可破解并伪造任意令牌。 推荐用 密码生成器 生成至少 32 字节的随机字符串作为 HMAC 密钥， 或用 UUID v4 作为密钥种子。本工具支持 UTF-8 字符串与 base64url 编码两种密钥输入格式， 后者可直接输入 32 字节随机二进制（避免字符集限制）。

NIST SP 800-57 给出的 RSA 安全强度对应关系：2030 年前 2048 位足够，2030 年后推荐 3072 位， 4096 位提供更高安全裕度但性能稍慢。实际选择需平衡安全性、性能与 token 长度：
- 2048 位：签名约 256 字节，base64url 后约 344 字符，目前主流选择，性能最佳
- 3072 位：签名约 384 字节，base64url 后约 512 字符，NIST 推荐的 2030 年后安全等级
- 4096 位：签名约 512 字节，base64url 后约 684 字符，安全裕度最高但 token 显著变大
本工具可在浏览器内本地生成 RSA 密钥对（基于 Web Crypto API 的 CSPRNG），输出 PEM 与 JWK 双格式。 生成的密钥仅本地保存，关闭页面即丢失，请及时复制保存。生产环境建议用 OpenSSL 等专业工具离线生成。

ECDSA（Elliptic Curve Digital Signature Algorithm，椭圆曲线数字签名算法）是基于 椭圆曲线离散对数问题（ECDLP）的非对称签名算法，由 NIST 在 FIPS 186-4 标准化。 与 RSA 基于大整数分解不同，椭圆曲线密码学（ECC）在同等安全强度下密钥与签名都显著更短：
- ES256（P-256 + SHA-256）：私钥约 32 字节，签名 64 字节（base64url 后约 86 字符），安全强度约等同于 RSA 3072 位
- RS256（2048 位）：私钥约 1190 字节，签名 256 字节（base64url 后约 344 字符）
即 ES256 的签名长度仅为 RS256 的 1/4，私钥长度约为 1/37，在移动端、IoT 设备、HTTP Header 等带宽敏感场景优势明显。
本工具支持 ES256（P-256）、ES384（P-384）、ES512（P-521）三种曲线，签名格式遵循 RFC 7518： 采用 ECDSA 原始拼接格式 r || s（r 与 s 各为曲线点位整数的固定长度大端字节），不含 ASN.1 DER 包装。

NIST 推荐的三条曲线对应 JWT 中的 ES256/ES384/ES512 算法，安全强度与适用场景如下：
- P-256（secp256r1）：256 位曲线，安全强度约 128 位，等同 RSA 3072 位。 JWT 生态最广泛，Apple Sign In、Google OAuth2、AWS Cognito 默认采用。性能最佳，token 最短。
- P-384（secp384r1）：384 位曲线，安全强度约 192 位，等同 RSA 7680 位。 适用于对长期安全等级要求更高的场景（如金融级、医疗级身份令牌）。
- P-521（secp521r1）：521 位曲线，安全强度约 256 位，等同 RSA 15360 位。 NIST 曲线中安全强度最高，但部分老旧库（如旧版 Java）支持较差，选用前需确认验签方环境。
选择建议：通用业务首选 P-256（ES256）；高合规要求选 P-384；P-521 仅在确有极高安全等级需求且验签方支持时使用。 本工具切换 ES 算法时会自动同步对应曲线，避免曲线与算法不匹配。

两者都是非对称签名，但底层算法差异显著。同等安全强度下的对比（数据来源：NIST SP 800-57）：
- 密钥长度：ES256 私钥 32 字节 vs RS256 私钥约 1190 字节（约 1/37）
- 签名长度：ES256 固定 64 字节 vs RS256 约 256 字节（约 1/4），base64url 后约 86 vs 344 字符
- 签发性能：ECDSA 签发比 RSA 快 5–10 倍（P-256 比 RSA-2048）
- 验签性能：RSA 验签略快于 ECDSA（RSA 验签只需公开指数运算）
- 安全强度：P-256 ≈ RSA-3072，比 RSA-2048 还高一个等级
选择建议：① 移动端、IoT、HTTP Header 受限场景用 ES256； ② 验签高并发、客户端广泛需兼容老系统的场景用 RS256； ③ 两者均可时优先 ES256，token 体积小、签发快、安全等级更高。
注意：ECDSA 签名非确定性（每次签发结果不同，因含随机数 k），同一密钥对同一 Payload 会产生不同签名，这是正常现象而非 Bug。

本工具内置 EC 密钥对生成器：选择算法为 ES256/ES384/ES512 → 选择曲线（P-256/P-384/P-521，默认随算法自动同步）→ 点击「生成新密钥对」按钮。生成过程基于浏览器原生 Web Crypto API 的 crypto.subtle.generateKey({ name: 'ECDSA', namedCurve: 'P-256' })， 使用操作系统 CSPRNG，质量与 OpenSSL 相当。输出格式：
- PEM 格式：私钥为 PKCS#8（-----BEGIN PRIVATE KEY-----）， 公钥为 SPKI（-----BEGIN PUBLIC KEY-----），兼容 OpenSSL、Java、Node.js 等
- JWK 格式：含 kty:"EC"、crv、x、y、d（私钥）字段，可用于 JWKS 端点
签名格式：Web Crypto 的 ECDSA sign() 默认输出 raw 拼接格式 （r 与 s 各为固定长度大端字节，P-256 时各 32 字节共 64 字节），直接符合 RFC 7518 ES 系列要求， 无需 ASN.1 DER 解包转换（这是 Web Crypto 相对其他库的便利之处）。 安全提示：EC 私钥请妥善保管，泄露后可签发任意令牌；d 字段是私钥标量，切勿公开。 想深入了解椭圆曲线原理与 ES vs RS 性能对比？参阅 椭圆曲线密码学与 ECDSA 签名实践。

none 算法表示无签名，JWT 第三段（Signature）为空字符串， 格式为 header.payload.（末尾有一个点）。RFC 7519 允许此算法仅用于调试与教学演示。 风险在于：任何人都可伪造 Payload 内容（如把 role: "user" 改为 role: "admin"）， 接收方无法验证令牌真实性。常见攻击场景：服务端未严格校验 alg 字段，攻击者把 Header 中的 {"alg":"HS256"} 改为 {"alg":"none"} 并清空签名段， 若服务端信任客户端传入的 alg 就会跳过验签。防御：服务端必须硬编码允许的算法白名单 （如仅接受 HS256/RS256），不读取 token 自身声明的 alg。本工具保留 none 算法仅用于演示此攻击， 签发结果会显示红色安全警告横幅。详见 JWT 安全实践。

本工具内置 RSA 密钥对生成器：选择算法为 RS256/RS384/RS512 → 选择密钥位数（2048/3072/4096）→ 点击「生成新密钥对」按钮。生成过程基于浏览器原生 Web Crypto API 的 crypto.subtle.generateKey，使用操作系统提供的密码学安全随机数生成器（CSPRNG）， 质量与 OpenSSL 等专业工具相当。生成结果同时输出 PEM 格式（用于 OpenSSL、Nginx、传统后端） 与 JWK 格式（用于 JWKS 端点、现代前端库）。安全提示： ① 密钥仅在浏览器内存中生成与展示，不会上传到任何服务器； ② 关闭页面后密钥即丢失，请及时复制保存；③ 生产环境建议用离线工具（如 OpenSSL）生成并妥善保管； ④ 私钥切勿泄露，公钥可公开分发。

三者都是 JOSE（JavaScript Object Signing and Encryption）工作组的标准，层层递进：
- JWS（JSON Web Signature，RFC 7515）：定义签名格式，即 header.payload.signature 三段式
- JWT（JSON Web Token，RFC 7519）：基于 JWS 的令牌规范，约束 Header 必含 alg、 Payload 为声明集合（iss/sub/aud/exp 等标准声明 + 自定义声明）
- JWE（JSON Web Encryption，RFC 7516）：定义加密格式，五段式 protected.encrypted_key.iv.ciphertext.tag，提供机密性（内容加密）而非仅完整性
关系：JWT 默认用 JWS 签名（不加密，内容可读）；若需机密性，可嵌套为 JWT-in-JWE（先签后加密）。 本工具签发的是未加密的 JWT（JWS 格式），任何人都可解码查看 Payload 内容， 仅靠签名保证防篡改。如需加密，请用 JWE 解码工具 了解 JWE 格式。

base64url 是 base64 的 URL 安全变体，差异在两个字符与 padding：
- base64 用 + 和 /，在 URL 中 + 会被解析为空格、/ 是路径分隔符，破坏 URL
- base64url 用 - 替换 +，用 _ 替换 /，并通常省略末尾的 = padding
JWT 经常放在 URL 参数、HTTP Header、Cookie 中传输，必须 URL 安全，故 RFC 7515 规定使用 base64url。 本工具签发与展示的 JWT 各段均为 base64url 编码。若你看到 JWT 含 + 或 /， 说明签发方实现不规范，可能导致 URL 解析错误。

常见失败场景与排查建议：
- Header JSON 不合法：如缺少 alg 字段、JSON 语法错误（多余逗号、引号未闭合）。 本工具实时校验并显示具体错误。
- Payload JSON 不合法：同上，Payload 必须是 JSON 对象（不能是数组或基本类型）。
- HMAC 密钥为空：HS 系列算法必须提供密钥。
- RSA 私钥格式错误：PEM 缺少 -----BEGIN ... PRIVATE KEY----- 标记， 或 JWK 缺少 kty/n/d 字段。本工具支持 PKCS#1 与 PKCS#8 两种 PEM 格式。
- EC 私钥格式错误：PEM 缺少 -----BEGIN PRIVATE KEY----- 标记， 或 JWK 缺少 kty:"EC"、crv、x、y、d 字段， 或 crv 与算法不匹配（如 ES256 必须用 P-256）。
- 算法与密钥不匹配：如选 RS256 但输入了 HMAC 密钥，或选 HS256 但输入了 RSA 私钥。 本工具根据算法类别动态切换密钥输入区，避免此问题。
- Web Crypto API 不可用：非安全上下文（HTTP 非 localhost）下 crypto.subtle 为 undefined。 请在 HTTPS 或 localhost 环境使用本工具。

本工具仅负责签发，不负责验签。服务端验签流程：① 拆分 JWT 为 Header、Payload、Signature 三段； ② base64url 解码 Header，读取 alg；③ 用对应算法与密钥对 base64url(Header) + "." + base64url(Payload) 重新计算签名； ④ 用常量时间比较（防止时序攻击）比对计算结果与 token 的 Signature 段； ⑤ 校验 Payload 的 exp（未过期）、nbf（已生效）、iss、aud 等声明。 关键安全点：服务端必须硬编码允许的算法白名单，不读取 token 自身声明的 alg， 否则会被 alg=none 攻击绕过。常见后端库：Node.js 的 jsonwebtoken、Java 的 jose4j、 Python 的 PyJWT。调试时可用 JWT 解码工具 查看 token 内容。

不会上传。本工具完全在浏览器内运行，所有 Header/Payload 解析、密钥处理、签名计算、 RSA 与 EC 密钥对生成均由 JavaScript 在你本地执行，输入的密钥与生成的 JWT 不会发送到任何服务器。 Web Crypto API 的所有操作（importKey、sign、generateKey） 均在浏览器沙箱内完成，密钥材料不离开设备内存。这对于调试真实业务的密钥尤为重要—— 生产密钥泄露会导致任意 JWT 被伪造。额外提示：① 生成 RSA 或 EC 密钥对后请及时复制保存， 关闭页面即丢失；② 不要在公共电脑上输入生产密钥；③ 调试完成后建议清除浏览器历史记录。

本工具与 JWT 解码工具 形成「签发 + 解析」闭环：
① 在本工具签发 JWT → 复制完整 token
② 粘贴到 JWT 解码工具 → 查看 Header/Payload 解码结果、过期状态、算法说明
③ 验证签发结果是否符合预期（声明字段、过期时间、算法安全等级）
④ 若需加密保护内容，可继续用 JWE 解码工具 了解 JWE 加密令牌格式
两者共享 JWT 标准声明字段说明（iss/sub/aud/exp/iat/nbf/jti）与算法说明表（HS256/RS256/ES256/none 等）， 体验一致。常见联调场景：服务端集成 JWT 认证时，先用本工具签发测试 token，再用解码工具验证客户端收到的 token 是否被中间件改写。