mermaid学习

JWT解决什么了问题

JWT本质是为了解决: 跨系统无状态可信身份传递问题

在不共享服务器内存、不依赖 session 的情况下，安全地告诉别的服务： “这个请求是谁发的，他有什么权限，这个凭证没被篡改。”

JWT出现前的模式:

传统 Season模式(单体时代)

Browser ──cookie(session_id)──> Server
Server ──查内存/Redis──> 用户是谁

问题	为什么严重
服务器有状态	扩容要做 session sticky 或集中存储
微服务难共享	每个服务都要连 session 库
跨域/跨系统难	Cookie 范围受限
性能开销	每次都查 Redis

JWT出现后

Browser ──JWT──> 任意服务
服务自己验签 → 直接信任身份

去中心化身份认证(无状态)

是为了适配 微服务/ 云原生 / API 架构 而诞生的技术

JWT过程

JWT 全程为 Json Web Token

JWT长什么样

常见的是 JWS（签名版 JWT）：

<base64url(header)>.<base64url(payload)>.<base64url(signature)>

• header：说明用什么算法、类型等，比如：

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

• payload：业务声明（claims），比如：

{"sub":"123","name":"Akabane","iat":170000,"exp":170000}

exp：是否过期

nbf：是否已生效

iss：签发者是否是你期望的（防别的系统签的 token 混进来）

aud：受众是否包含你的服务（防“别的服务的 token”拿来调用你）

iat：可选做时间合理性/回放窗口检查

业务字段：scope/roles/tenant 等是否满足接口权限

• signature：对前两段做签名/MAC 的结果（防篡改）

base64url：是 base64 的 URL 安全变体（+→-，/→_，去掉尾部 =）。

注意事项

1. JWT是无状态的

JWT 是无状态的，后端是没有seasion 来维护的，你没法让一个用户立马 回收/下线

所以 access token 要设置的时间比较短，jwt过期后，后端过期再自动续发【refresh token】

sequenceDiagram
    autonumber
    participant B as Browser(前端)
    participant S as API Server(业务后端)

    B->>S: 1. 登录(账号密码)
    S->>S: 2. 校验身份
    S->>B: 3. 返回 Access JWT(可选: Refresh Token)

    B->>S: 4. 调用接口\nAuthorization: Bearer 
    S->>S: 5. 验签/exp/iss/aud/权限
    S->>B: 6. 返回数据

    alt JWT过期
        B->>S: 7. 刷新(携带Refresh Token 或重新登录)
        S->>B: 8. 返回新JWT
    end

2.Refresh Token

更现代的 Seasion-Cookie 的做法

老时代	现代做法
session_id	refresh_token
session存储	refresh会话表
每次请求查session	只在续期时查
所有接口依赖状态	只有refresh依赖状态

为什么更优:

项目	传统Session	Refresh机制
状态频率	每个请求查	仅刷新查
扩展性	差	好
JWT性能	无	高
可撤销	有	有
微服务传播	难	极易

当系统需要有踢人下线的功能的时候，就可以采用这样的方法

Payload和Secret事项

• Payload 明文可读，切勿存敏感数据
• 定期轮换 Secret，缩小泄露风险窗口
• 始终启用 HTTPS，防止中间人攻击

Secret 生产环境切勿硬编码，使用专业密钥管理服务（Vault, AWS KMS…）