上一篇我们讲了：
《为什么很多企业放弃纯 JWT，而选择 Token + Redis？》
很多人这时候会有一个疑问：
JWT 到底是什么？为什么：
- JWT 不查库就能认证？
- JWT 为什么不能伪造？
- JWT 为什么说"无状态"？
- JWT 为什么不能存敏感信息？
- JWT 为什么又无法主动失效？
今天我们从工程视角，
真正讲透： JWT 的底层原理。
一、JWT 到底是什么
JWT 全称：JSON Web Token
本质上 就是：
一个"自带身份信息"的 Token
传统 Token：
可能只是：
abc123服务端：
必须查 Redis / DB：
这个 token 对应谁？而 JWT：
自己就带着：
bash
{
"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 xxxAccessToken 过期：
返回：
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鉴权
彻底讲透：