JWT身份认证原理介绍

目录

• 传统的身份认证特点
• JWT的身份认证特点
• JWT的结构解析
• JWT 的工作流程
• 安全注意事项

---

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

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

1. Header（头部）

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

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

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

2. 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 中放置密码等敏感信息。这里也是一个安全检测项。

3. Signature（签名）

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

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

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

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

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

xxxxx.yyyyy.zzzzz

---

JWT 的工作流程

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

1. 用户登录：用户向认证服务器发送用户名和密码。

2. 验证凭据：认证服务器验证用户名和密码是否正确。

3. 创建 JWT：验证成功后，服务器生成 JWT。其中：

   • Header 指定算法。
   • Payload 包含用户ID、角色、过期时间等信息。
   • Signature 使用一个只有服务器知道的密钥（Secret），根据 Header 和 Payload 生成。

4. 返回 JWT：服务器将生成的 JWT 返回给客户端（通常是放在 HTTP 响应的 Authorization 头或 Body 中）。

5. 客户端存储：客户端（通常是浏览器）收到后，将其存储起来（常用 localStorage 或 sessionStorage）。

6. 携带 JWT 发起请求：此后，客户端向受保护的 API 发起的任何请求，都必须在 HTTP 请求头中带上 JWT（通常使用 Authorization: Bearer <token> 格式）。

7. 服务器验证 JWT：API 服务器收到请求：

   • 检查签名：使用相同的密钥对 JWT 的前两部分重新计算签名，并与第三部分对比，验证令牌是否有效且未被篡改。
   • 检查有效期：检查 Payload 中的 exp 字段，确保令牌没有过期。
   • 检查签发者（可选）：检查 iss 字段是否可信。

8. 返回响应：验证通过后，服务器认为请求来自一个已认证的用户，并根据 Payload 中的信息（如用户角色）处理请求并返回结果。

---

安全注意事项

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

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

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

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

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