JSON Web Token (JWT) 是一种开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于在各方之间作为 JSON 对象安全地传输信息。这些信息可以被验证和信任，因为它是数字签名的。

JWT主要是用来替代取代传统的身份认证机制。

传统的身份认证特点

状态性（Stateful）：服务器需要在其内存或数据库中存储每个用户的会话信息（Session）。

扩展性差：在分布式或微服务架构中，用户请求可能被负载均衡到不同的服务器上。这就要求所有服务器必须能访问一个共享的会话存储中心（如 Redis 集群），增加了复杂性。

跨域问题：让 Cookie 在多个不同的域下正常工作需要额外配置。

JWT的身份认证特点

无状态性（Stateless）：服务器不存储任何用户会话信息。用户的登录状态和信息直接编码在 JWT 令牌本身中。

自包含（Self-contained）：令牌本身包含了所有需要的用户信息（如用户ID、角色等），服务器只需验证令牌的有效性即可信任其中的内容。

易于跨域和传输：JWT 可以放在 HTTP 请求头（Authorization Header）、POST 参数或甚至 URL 中。由于它只是一个字符串，可以轻松地在不同域和服务之间传递。

JWT的结构解析

JWT可以看成是一串多个JSON信息串拼接成的Token。

JWT的结构：

一个 JWT 看起来就是一串很长的、由点（.）分隔的字符串，例如：

xxxxx.yyyyy.zzzzz

它实际上由三部分组成，对应着三个点作分隔符：

Header（头部）

作用：描述令牌的基本信息，如类型（即 JWT）和所使用的签名算法（如 HMAC SHA256 或 RSA）。

内容：一个 JSON 对象，例如 {"alg": "HS256", "typ": "JWT"}

存储方式：这个 JSON 对象会经过 Base64Url 编码，形成 JWT 的第一部分（xxxxx）。
Payload（负载）

作用：携带你想要传递的"声明"（Claims）。声明就是关于实体（通常是用户）和其他数据的语句。

内容：一个 JSON 对象，包含三种类型的声明：

注册声明（Registered claims）：预定义的一些标准字段，非强制但推荐使用。例如：
- iss (issuer)：签发者
- exp (expiration time)：过期时间
- sub (subject)：主题
- aud (audience)：接收方
- iat （issued at time）：JWT 签发时间
- exp （expiration time）：JWT 的过期时间
- ......
存储方式：这个 JSON 对象也会经过 Base64Url 编码，形成 JWT 的第二部分（yyyyy）。

⚠️ 重要提示：Header 和 Payload 只是经过编码（Base64Url），并没有加密！任何人都可以解码它们并看到原始内容。因此，绝对不能在 Payload 中放置密码等敏感信息。这里也是一个安全检测项。
Signature（签名）

作用：这是 JWT 最核心的部分，用于防止令牌被篡改，确保我们信任其内容。

生成方式：将编码后的 Header、编码后的 Payload、以及一个密钥（Secret）通过 Header 中指定的签名算法（如 HS256）进行签名。

伪代码：Signature = HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

验证方式：服务器收到 JWT 后，会用同样的密钥和算法对前两部分重新生成一个签名。如果新生成的签名与 JWT 中附带的第三部分签名完全一致，则证明令牌未被篡改（因为攻击者没有密钥，无法生成有效签名）。同时，也证明了发送者拥有密钥（通常是签发令牌的服务器）。

最终，将这三个 Base64Url 字符串用点连接起来，就构成了一个完整的 JWT。
xxxxx.yyyyy.zzzzz

JWT 的工作流程

这个流程展示了 JWT 如何实现无状态的身份验证，客户端只需在每次请求中携带 token，服务器通过验证签名和声明来判断请求的合法性，无需有一台中央服务器来维护用户会话状态。

用户登录：用户向认证服务器发送用户名和密码。
验证凭据：认证服务器验证用户名和密码是否正确。
创建 JWT：验证成功后，服务器生成 JWT。其中：
- Header 指定算法。
- Payload 包含用户ID、角色、过期时间等信息。
- Signature 使用一个只有服务器知道的密钥（Secret），根据 Header 和 Payload 生成。
返回 JWT：服务器将生成的 JWT 返回给客户端（通常是放在 HTTP 响应的 Authorization 头或 Body 中）。
客户端存储：客户端（通常是浏览器）收到后，将其存储起来（常用 localStorage 或 sessionStorage）。
携带 JWT 发起请求：此后，客户端向受保护的 API 发起的任何请求，都必须在 HTTP 请求头中带上 JWT（通常使用 Authorization: Bearer <token> 格式）。
服务器验证 JWT：API 服务器收到请求：
- 检查签名：使用相同的密钥对 JWT 的前两部分重新计算签名，并与第三部分对比，验证令牌是否有效且未被篡改。
- 检查有效期：检查 Payload 中的 exp 字段，确保令牌没有过期。
- 检查签发者（可选）：检查 iss 字段是否可信。
返回响应：验证通过后，服务器认为请求来自一个已认证的用户，并根据 Payload 中的信息（如用户角色）处理请求并返回结果。

安全注意事项

密钥保护: 服务器密钥必须保密，且足够复杂；

HTTPS: 所有通信应通过 HTTPS 进行，防止 token 被窃取；

合理过期时间: 设置适当的过期时间，平衡安全性和用户体验；

敏感信息: 不要在 payload 中存放敏感信息（如密码）；

注销处理: JWT 无法在有效期内主动失效，需结合黑名单或短期有效期策略；

JWT身份认证原理介绍

传统的身份认证特点

JWT的身份认证特点

JWT的结构解析

JWT 的工作流程

安全注意事项