JWT（Json Web Token）概述

承接 OAuth 和 OIDC 的内容：
通常情况下，id_token 都是 JWT，而放在 Bearer xxx 里的 Access Token 有时是 JWT ，有时又会用 opaque token （不透明 token）

JWT，全称 JSON Web Token，是一种可携带声明信息的字符串格式。

JWT 不是“加密后的用户信息”，而是“可被验证真伪的声明载体”。JWT 里携带的信息都是可以被公开解码成明文的。

格式

JWT 由三部分构成，用 . 分隔：

Header.Payload.Signature

举个典型例子：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJ1c2VySWQiOjEyMywicm9sZSI6ImFkbWluIiwiZXhwIjoxNzAwMDAwMDAwfQ
.
abc123signature

Header

其实就是一个 JSON，只不过这个 JSON 会被 Base64Url 编码。

这个 JSON 通常包括：

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

也就是签名用的算法和类型。

Payload

也是个 JSON，真正有用的信息放里面。

里面很可能会放用户 ID 之类的东西，当然有时也可以放用户邮箱等等。不过由于 Payload 默认是可以被解码看到的，所以不会往里面放敏感信息。

这个 JSON 最后也会被 Base64Url 编码。

Signature

签名部分唯一的作用就是防止 Token 被篡改，用于校验数据完整性。

通常情况下，服务端会把 JWT 的前两部分用 Header 里提到的算法签名（用于生成签名的密钥一般会被保管在后端的环境变量等位置）

完成后的签名，再加上前两部分，最终形成完整的 JWT。

意义

传统 Session 登录的缺陷

传统做法：

• 登录成功后，服务端创建 session

• session id 放进 cookie

• 浏览器后续自动带 cookie

• 服务端查 session

优点：

• 简单

• cookie 自动携带

• session 可控，易失效

缺点：

• 服务端要存 session 状态

• 分布式场景要共享 session 或做粘性会话

• 前后端分离、移动端、多终端时扩展性没那么优雅

这叫有状态认证。

JWT 的思路

JWT 的思路是：

1. 用户登录成功后

2. 服务端签发一个 token

3. token 里包含用户身份、过期时间等信息

4. 客户端以后每次请求都带上这个 token

5. 服务端只要验证 token 的签名和有效期，就知道请求者是谁

注意这里的关键变化：

• 服务端不一定要存 session

• 用户身份信息跟着 token 一起走

• 服务端主要做“验证”，不一定做“查找会话”

这就叫常说的无状态认证。