企业认证与安全体系（三）：一篇讲透 JWT 原理与企业级实践

上一篇我们讲了：

《为什么很多企业放弃纯 JWT，而选择 Token + Redis？》

很多人这时候会有一个疑问：

JWT 到底是什么？

为什么：

• JWT 不查库就能认证？
• JWT 为什么不能伪造？
• JWT 为什么说"无状态"？
• JWT 为什么不能存敏感信息？
• JWT 为什么又无法主动失效？

今天我们从工程视角，

真正讲透： JWT 的底层原理。

---

一、JWT 到底是什么

JWT 全称：JSON Web Token

本质上 就是：

一个"自带身份信息"的 Token

---

传统 Token：

可能只是：

abc123

服务端：

必须查 Redis / DB：

这个 token 对应谁？

---

而 JWT：

自己就带着：

{
  "userId": 1001,
  "role": "admin"
}

所以：

JWT 是"自描述 Token"

---

二、JWT 的三段结构（非常重要）

JWT 长这样：

xxxxx.yyyyy.zzzzz

注意：

中间有两个点

分成：

部分	作用
Header	头部
Payload	载荷
Signature	签名

---

即：

Header.Payload.Signature

---

三、JWT Header（头部）

Header 描述：

"这个 Token 怎么签名"

例如：

{
  "alg": "HS256",
  "typ": "JWT"
}

含义：

字段	含义
alg	签名算法
typ	Token类型

---

常见算法：

算法	说明
HS256	HMAC-SHA256（最常见）
RS256	RSA 非对称加密
ES256	ECC 椭圆曲线

---

四、JWT Payload（载荷）

Payload 保存：用户信息

例如：

{
  "userId": 1001,
  "username": "admin",
  "role": "ADMIN",
  "exp": 1711111111
}

---

常见字段：

字段	含义
sub	用户ID
exp	过期时间
iat	签发时间
iss	签发者

---

这里：

Payload 只是 Base64 编码

注意：不是加密！

所以：

JWT 里的内容任何人都能解码

---

五、为什么 JWT 不能存敏感信息（高频）

很多新手 喜欢：

{
  "password":"123456"
}

这是：非常危险

因为：

JWT 只是：Base64 编码

不是：加密

任何人都能：Base64 解码看到里面内容。

---

所以：

JWT 绝不能存：

• 密码
• 身份证
• 银行卡
• 手机号
• 隐私数据

---

六、JWT Signature（签名）

这是 JWT 最核心部分

作用：防篡改

---

Signature 计算方式：

HMACSHA256(
   base64(Header) + "." + base64(Payload),
   secret
)

例如：

Header.Payload

加上：

secretKey

生成：

Signature

---

七、JWT 为什么无法伪造

假设 黑客修改 Payload：

原来：

{
  "role":"USER"
}

黑客改成：

{
  "role":"ADMIN"
}

---

问题来了：Signature 会变

因为 签名计算：包含 Payload

---

而黑客 没有：

secretKey

所以：

无法生成正确签名

---

服务端：

验签失败：

JWT 非法

直接拒绝。

---

八、JWT 为什么叫"无状态"

传统 Session 服务端：

保存用户状态

而 JWT 用户信息 就在 Token 里。

服务端：

只需要：

验签

即可。

无需：

• 查 Session
• 查 Redis
• 查数据库

所以：

JWT 是无状态认证

---

九、JWT 的巨大优势

JWT 最大优势：

性能极高

因为：

本地即可验签

---

不需要：

Redis
数据库
Session中心

特别适合：

• 高频接口
• 微服务
• Gateway
• 分布式系统

---

十、JWT 最大问题（企业重点）

JWT 最大问题：

无法主动失效

---

例如：

JWT：

有效期2小时

只要：

没过期

服务端：

就必须认

---

即使：

• 用户退出登录
• 修改密码
• 被踢下线
• 风险设备
• 账号冻结

JWT：

仍然有效。

---

所以：

企业很少纯 JWT

而是：

JWT + Redis

混合方案。

---

十一、企业真实 JWT 方案（非常重要）

企业里：

通常：

Token	存储
AccessToken	JWT
RefreshToken	Redis

---

JWT：

负责：

高频访问认证

Redis：

负责：

会话生命周期管理

包括：

• 踢下线
• 风控
• 单设备登录
• Token撤销
• 黑名单

---

十二、JWT 与 HTTPS 的关系

很多人：

误以为：

JWT 自带加密

其实：

JWT 默认不加密

所以：

JWT 必须跑 HTTPS

否则：

抓包直接偷Token

---

所以：

真实链路：

HTTPS
   ↓
JWT
   ↓
Authorization Header

---

十三、JWT 在 Android / APP 中的真实使用

移动端 通常：

Authorization: Bearer xxx

---

AccessToken 过期：

返回：

401 Unauthorized

---

客户端 自动：

refreshToken 刷新

获取：

newAccessToken

然后：

自动重放请求

用户：

完全无感

---

十四、JWT 真正的定位（非常重要）

很多人：

把 JWT 神化了。

实际上：

JWT 本质只是：

Token 的一种格式

它解决的是：

"身份信息自描述"

问题。

而：

企业真正关心的：

是：

"会话是否可控"

所以：

后面：

Redis：

才会进入体系。

---

十五、最终核心理解（建议背下来）

JWT：

本质上是：

一个带签名的自描述 Token

特点：

• 自带用户信息
• 无状态
• 本地可验签
• 性能高
• 分布式友好

但：

也存在：

无法主动失效

问题。

因此：

企业通常采用：

JWT + Redis

混合方案。

JWT：

负责：

高频认证

Redis：

负责：

会话生命周期管理

这才是真正企业里的：

JWT 使用方式。

---

下篇预告

下一篇我们继续：

《企业认证与安全体系（四）：Spring Security + JWT + Redis 企业级认证实战》

真正进入：

• Spring Security
• Filter链
• OncePerRequestFilter
• Authentication
• SecurityContextHolder
• Redis
• Gateway鉴权

彻底讲透：

企业真实登录鉴权流程。