JWT（JSON Web Token）是一种开放标准（RFC 7519），用于在各方之间安全地传输信息。它由三部分组成：Header（头部）、Payload（载荷）和Signature（签名），使用点号（.）分隔。JWT 常用于身份认证和信息交换，由于其自包含特性，服务器无需存储会话信息即可验证用户身份。典型应用场景包括：单点登录（SSO）、API 鉴权、微服务间通信等。

Header：包含令牌类型（typ）和签名算法（alg），如 HS256、RS256 等。
Payload：包含声明（Claims），如用户 ID（sub）、签发时间（iat）、过期时间（exp）等。
Signature：使用 Header 中指定的算法对前两部分进行签名，确保数据完整性。

JWT 使用 Base64URL 编码（而非标准 Base64），区别在于：将 + 替换为 -，将 / 替换为 _，并去除尾部 = 填充字符，使其可直接在 URL 中安全传输。

HS256（HMAC with SHA-256）：使用对称密钥，即签发和验证使用同一个密钥。适合单体应用或内部微服务通信，密钥管理相对简单，但需要妥善保护密钥。
RS256（RSA with SHA-256）：使用非对称密钥对，私钥签发、公钥验证。适合分布式系统，公钥可以安全分发，无需共享私钥。常用于 OpenID Connect、OAuth 2.0 等场景。

选择建议：小规模应用或内部服务用 HS256 更简单；多服务架构或需要第三方验证的场景推荐 RS256。

exp（Expiration Time）：Unix 时间戳（秒），表示 Token 在此时间之后失效。建议设置较短的过期时间（如 15 分钟到 2 小时），配合 Refresh Token 机制实现安全续期。

安全注意事项：

• 始终使用 HTTPS 传输 JWT，防止中间人攻击。
• 密钥强度要足够（HS256 建议 256 位以上随机密钥）。
• 不要在 Payload 中存储敏感信息（JWT 仅编码非加密，任何人都可解码查看）。
• 设置合理的过期时间，避免长期有效的 Token 泄露后被滥用。
• 避免使用 none 算法，它允许绕过签名验证。
• 在服务端验证时，明确指定允许的算法列表，防止算法降级攻击。

none 算法：JWT 规范中定义的一种特殊算法，表示不进行签名。攻击者可以修改 Header 中的 alg 为 "none"，并删除签名部分，某些配置不当的服务端可能会接受这种未签名的 Token，从而导致身份伪造。

防范措施：在服务端 JWT 验证库中显式禁用 none 算法，并始终指定允许的算法白名单（如只接受 HS256、RS256 等），不要依赖库的默认配置。

Session 认证：服务端存储会话状态，客户端仅持有 Session ID（Cookie）。优点是服务端可主动失效会话；缺点是需要服务端存储，扩展性受限。
JWT 认证：Token 自包含用户信息，服务端无状态。优点是易于水平扩展、适合分布式系统和移动端；缺点是 Token 签发后无法主动失效（需配合黑名单或短过期时间）。

选择建议：传统 Web 应用可用 Session；API 服务、微服务、移动端应用推荐 JWT。