JWT 解释：JSON Web 令牌如何工作
JSON Web 令牌 (JWT) 在现代 Web 身份验证中无处不在 - 登录几乎所有应用程序都可能涉及 JWT。然而，它们被广泛误解，而这种误解会导致真正的安全错误。简单来说，这就是它们的实际工作原理。
什么是 JWT
JWT 是一种紧凑、独立的令牌，它携带有关用户或会话的信息（“声明”）。登录后，服务器会向您颁发 JWT；您将其与每个请求一起发回，并且服务器信任它，因为它是经过加密签名的。这是一种在服务器不存储会话状态的情况下证明“我已通过身份验证”的方法。
三个部分
JWT 是由点分隔的三个 Base64URL 编码部分：header.payload.signature。
- 标头 — 令牌类型和签名算法。
- 有效负载 - 声明：用户 ID、角色、到期时间等。
- 签名 - 证明令牌未被篡改的加密印章。
将任何令牌粘贴到我们的 JWT 解码器中以查看这些部分的布局。该标准在 RFC 7519 中定义。
关键的安全警告
这是人们犯的错误：标头和有效负载仅Base64 编码，未加密。任何拦截 JWT 的人都可以立即解码并读取有效负载。因此，切勿将秘密（密码、敏感个人数据）放入 JWT 有效负载中。签名可以防止篡改，而不是读取。 （请参阅我们的指南，了解为什么 Base64 不安全。）
签名如何保护您
服务器使用密钥对令牌进行签名。如果有人更改了有效负载，签名将不再匹配，服务器会拒绝它。这就是让服务器信任它未存储的令牌的原因 - 它可以通过数学方式验证真实性。
到期事宜
由于 JWT 是独立的，因此您无法在过期之前轻松“撤销”它。这就是为什么精心设计的令牌具有短暂的有效期（exp 声明），并且应用程序使用刷新令牌来颁发新令牌。长期存在的 JWT 存在安全风险。
签名算法：HMAC 与 RSA
标头指定了令牌的签名方式，有两个常见系列。 HMAC（例如 HS256）使用单个共享密钥进行签名和验证 - 很简单，但验证的每一方都必须持有该密钥。 RSA/ECDSA（例如 RS256）使用私钥进行签名并使用单独的公钥进行验证，因此您可以让许多服务验证令牌，而无需共享签名密钥。对于分布式系统，非对称签名通常是更安全的选择；对于单个后端，HMAC 就可以了。
在浏览器中存储 JWT 的位置
一个实际的安全问题：令牌位于客户端的哪里？ localStorage 很方便，但可以被任何 JavaScript 读取，这使得它容易受到窃取令牌的 XSS 攻击。 HttpOnly cookie 无法被 JavaScript 读取，可以缓解 XSS，但需要 CSRF 保护。没有完美的答案——这是一种权衡——但在存在任何 XSS 风险的网站上将敏感令牌存储在普通的 localStorage 中是值得避免的已知手段。
“alg: none”漏洞
一个著名的 JWT 陷阱：一些库历史上接受令牌的算法设置为“none”，这意味着根本没有签名 - 让攻击者伪造他们喜欢的任何有效负载。教训是始终使用明确的预期算法来验证签名，并且永远不要相信令牌本身声明的算法。使用维护良好的库，固定算法，JWT 仍然是一个强大的、防篡改的凭证。
底线
JWT 是一个经过签名的、独立的令牌，由三个 Base64URL 部分组成：标头、有效负载和签名。签名保证完整性，但任何人都可以读取有效负载 - 因此请保密，设置较短的到期时间，并在需要检查令牌时使用工具对其进行解码。
