JWT（JSON Web Token）是一种开放标准（RFC 7519），用于在各方之间安全地传输信息。JWT由三部分组成：Header（头部）、Payload（载荷）和Signature（签名），通过点号（.）连接。它广泛应用于API认证、单点登录（SSO）和信息交换场景。
Header（头部）：包含Token类型和签名算法，例如 {"alg":"HS256","typ":"JWT"}。alg字段指定签名算法，typ字段指定Token类型（通常为JWT）。
Payload（载荷）：包含声明（Claims），即关于实体（通常是用户）和其他数据的声明。标准声明包括：sub（主题）、iss（签发者）、aud（受众）、exp（过期时间）、iat（签发时间）、nbf（生效时间）等。
Signature（签名）：使用Header中指定的算法对Base64Url编码的Header和Payload进行签名，确保Token未被篡改。签名公式为：HMACSHA256(base64Url(header) + "." + base64Url(payload), secret)
第一步：配置Header。在Header区域输入JWT头部信息，通常包含算法类型alg和Token类型typ。工具默认提供HS256算法，你也可以切换到HS384或HS512以获得更高安全性。
第二步：填写Payload。在Payload区域输入JSON格式的数据。Payload中包含的声明分为三类：标准声明（如exp、iat、sub）、公共声明（自定义但不冲突的声明）和私有声明（应用内部使用的声明）。建议至少包含sub（用户ID）和exp（过期时间）声明。
第三步：设置Secret Key。Secret Key是HMAC签名的核心，必须足够强（建议256位以上）。你可以点击"随机生成密钥"按钮自动生成一个强密钥，也可以手动输入。
第四步：生成Token。点击"生成JWT Token"按钮，工具会使用Web Crypto API在浏览器端完成签名计算，生成的Token以"Header.Payload.Signature"格式显示。三部分分别用不同颜色标识，便于识别。
第五步：验证签名。生成Token后，你可以点击"验证签名"按钮，工具会重新计算签名并与Token中的签名对比，确认Token的完整性。
• API认证：用户登录后服务端签发JWT，客户端在后续请求中携带JWT进行身份验证，替代传统的Session机制。
• 单点登录（SSO）：JWT可以在不同域名间传递用户信息，实现一次登录、多处访问的单点登录体验。
• 信息交换：JWT可以在不信任的各方之间安全传输信息，签名确保信息未被篡改。
• 微服务认证：在微服务架构中，JWT作为服务间通信的认证凭证，避免了每次请求都去验证用户身份的开销。
• Secret Key必须妥善保管，不要在代码中硬编码，建议使用环境变量或密钥管理服务。
• Payload中的数据是Base64编码的，任何人都可以解码查看，不要在Payload中存放密码等敏感信息。
• 始终设置合理的exp（过期时间），避免Token长期有效带来的安全风险。
• 使用HTTPS传输JWT，防止Token在传输过程中被截获。
• 定期轮换Secret Key，降低密钥泄露后的影响范围。
这三种都是HMAC签名算法，区别在于使用的哈希算法不同：HS256使用SHA-256（推荐默认）、HS384使用SHA-384、HS512使用SHA-512。数字越大安全性越高，但计算开销也越大。对于一般Web应用，HS256已足够安全。
本工具完全在浏览器端运行，所有数据（包括Secret Key）仅在本地处理，不会上传到任何服务器。但请注意，JWT的Payload部分是Base64编码的，任何人都可以解码查看内容，因此不要在Payload中存放敏感信息（如密码）。
在Payload中使用exp（过期时间）声明来设置有效期。exp的值是Unix时间戳（秒），表示Token的过期时间点。例如设置exp为当前时间+3600表示Token在1小时后过期。建议同时设置iat（签发时间）和exp。
Secret Key（密钥）是HMAC签名的核心，必须满足：1）足够长（建议至少32字节/256位）；2）包含大小写字母、数字和特殊字符的随机组合；3）妥善保管，不要泄露；4）定期更换。
常见原因包括：1）Secret Key不匹配（验证时使用的密钥与生成时不一致）；2）算法选择错误（Header中的alg与实际签名算法不一致）；3）Token被篡改（Signature部分被修改）。请确保使用相同的Secret Key和算法进行验证。
Payload中可以放任何JSON格式的数据，但建议遵循JWT标准声明规范。常用标准声明包括：sub（主题/用户ID）、iss（签发者）、aud（受众）、exp（过期时间）、iat（签发时间）、nbf（生效时间）、jti（唯一标识）等。自定义声明应避免使用保留名称。
Session认证需要在服务端存储Session数据，每次请求都要查询Session。JWT将认证信息编码在Token中，服务端只需验证签名即可确认Token有效性，无需存储Session，更适合分布式和微服务架构。但JWT一旦签发无法主动撤销，需要通过设置较短的过期时间来控制。
通常采用"双Token"策略：使用短期有效的Access Token（如15分钟）和长期有效的Refresh Token。Access Token过期后，客户端用Refresh Token向服务端请求新的Access Token。Refresh Token通常存储在HttpOnly Cookie中以提高安全性。