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
它实际上由三部分组成，对应着三个点作分隔符：
[*]Header（头部）
作用：描述令牌的基本信息，如类型（即 JWT）和所使用的签名算法（如 HMAC SHA256 或 RSA）。
内容：一个 JSON 对象，例如 {"alg": "HS256", "typ": "JWT"}
存储方式：这个 JSON 对象会经过 Base64Url 编码，形成 JWT 的第一部分（xxxxx）。
[*]Payload（负载）
作用：携带你想要传递的“声明”（Claims）。声明就是关于实体（通常是用户）的可公开的信息 、 数据信息。
内容：一个 JSON 对象，包含三种类型的“声明”（Claims）：
[*]注册声明（Registered claims）：JWT预定义的一些标准字段，非强制但推荐使用。常见的有：
[*]iss (issuer)：签发者
[*]exp (expiration time)：过期时间
[*]sub (subject)：主题
[*]aud (audience)：接收方
[*]iat （issued at time）：JWT 签发时间
[*]exp （expiration time）：JWT 的过期时间
[*]......
[*]公开声明(Public Claims)
已经在一个公共的注册表中（如 IANA JWT Registry）注册过，或者使用一个能避免冲突的名字（如包含一个完整的URL）。
[*]私有声明(Private Claims)
私下约定的自定义声明。它们既不是注册声明，也没有按照公共声明的方式去避免名字冲突。
存储方式：这个 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，服务器通过验证签名和声明来判断请求的合法性，无需有一台中央服务器来维护用户会话状态。
[*]用户登录：用户向认证服务器发送用户名和密码。
POST /api/login HTTP/1.1
Host: example.com
Content-Type: application/json
{
"username": "alice",
"password": "password123"
}
[*]验证凭据：认证服务器验证用户名和密码是否正确。
[*]创建 JWT：验证成功后，服务器生成 JWT。其中：
[*]Header 指定算法。
{
"alg": "HS256",
"typ": "JWT"
}
→ Base64Url 编码后: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
[*]Payload 包含用户ID、角色、过期时间等信息。
{
"sub": "1234567890",
"name": "Alice",
"iat": 1516239022,
"exp": 1516242622
}
→ Base64Url 编码后: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9
[*]Signature 使用一个只有服务器知道的密钥（Secret），根据 Header 和 Payload 生成。
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
"your-256-bit-secret" // 服务器密钥
)
→ 计算得到签名: SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
[*]返回 JWT：服务器将生成的 JWT 返回给客户端（通常是放在 HTTP 响应的 Authorization 头或 Body 中）。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
[*]客户端存储：客户端（通常是浏览器）收到后，将其存储起来（常用 localStorage 或 sessionStorage）。
[*]携带 JWT 发起请求：此后，客户端向受保护的 API 发起的任何请求，都必须在 HTTP 请求头中带上 JWT（通常使用 Authorization: Bearer格式）。
[*]重新计算签名：服务器验证 JWT：API 服务器收到请求：
[*]7.1 检查签名：使用相同的密钥对 JWT 的前两部分重新计算签名，并与第三部分对比，验证令牌是否有效且未被篡改。
[*]7.2 检查有效期：检查 Payload 中的 exp 字段，确保令牌没有过期。
[*]7.3 检查签发者（可选）：检查 iss 字段是否可信。
[*]返回响应：验证通过后，服务器认为请求来自一个已认证的用户，并根据 Payload 中的信息（如用户角色）处理请求并返回结果。
工作时序图：
安全注意事项
密钥保护: 服务器密钥必须保密，且足够复杂；
HTTPS: 所有通信应通过 HTTPS 进行，防止 token 被窃取；
合理过期时间: 设置适当的过期时间，平衡安全性和用户体验；
敏感信息: 不要在 payload 中存放敏感信息（如密码）；
注销处理: JWT 无法在有效期内主动失效，需结合黑名单或短期有效期策略；
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]