JSON Web Token（JWT）是如何工作的？

Question

IT Interview Practice · Accepted Answer

**JSON Web Token（JWT）** 是一种紧凑、URL-safe、自包含的 token，携带关于用户的 claims。服务器对它签名一次；此后就能在每个 request 上**验证**该 token 而无需查询数据库——这正是让基于 JWT 的认证成为 *stateless* 的原因。

## 结构：三个 base64url 部分

一个 JWT 是 `header.payload.signature`，三个用点连接的 base64url 编码段：

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (claims)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** —— 签名算法，例如 `{ "alg": "HS256", "typ": "JWT" }`。
- **Payload** —— **claims**：标准的如 `sub`（subject/user id）、`exp`（过期）、`iat`（签发时间）、`iss`（issuer），外加任意自定义字段（`role`、`email`）。
- **Signature** —— 用一个 secret 或私钥在 header 和 payload 之上计算得出。

> Payload 是**编码的，不是加密的**。任何人都能 base64-decode 并读取它，所以永远不要把密码或秘密放进 JWT。

## 签名与验证如何工作

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256**（对称）：同一个 secret 既签名又验证。简单，但每个验证方都必须持有该 secret。
- **RS256**（非对称）：**私钥**签名，**公钥**验证。认证服务器保管私钥；其他服务用公钥验证，永远无法铸造 token。

在每个 request 上，服务器对收到的 header+payload 重新计算 signature 并进行比较。如果它们匹配且 `exp` 在未来，token 就被信任——无需 session store。

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // 若被篡改或过期则抛出
  // claims.sub === "123"
} catch (e) {
  // 拒绝：无效或已过期
}
```

## 难点：撤销（revocation）

由于验证是 stateless 的，你**无法**仅靠在服务器端"删除"来在一个 token 过期前使其失效。常见的缓解手段：

- 让 access token **短命**（5–15 分钟），并与一个更长命的 **refresh token** 配对。
- 维护一个小的**denylist**，记录被撤销的 token id（`jti`）用于登出/失陷——这会重新引入一点 state。
- 轮换签名密钥。

## 存储的取舍

| 存储 | 优点 | 缺点 |
|---|---|---|
| `httpOnly` cookie | JS 无法读取（对 XSS 更安全） | 需要 CSRF 保护 |
| `localStorage` | 简单，无 CSRF | 暴露于 XSS |

## 为什么这很重要

JWT 为跨 API、microservice 和 SPA 的 stateless 认证提供动力——一个服务仅凭验证签名就能信任一个 request，无需共享的 session store。但同样的无状态性正是经典的面试陷阱：token 无法轻易撤销、payload 可读，而 `alg` 混淆或缺失过期检查都是真实的漏洞。准确知道签名保护什么、不保护什么，是安全使用 JWT 的关键。

存储	优点	缺点
`httpOnly` cookie	JS 无法读取（对 XSS 更安全）	需要 CSRF 保护
`localStorage`	简单，无 CSRF	暴露于 XSS

结构：三个 base64url 部分

签名与验证如何工作

难点：撤销（revocation）

存储的取舍

为什么这很重要

相关问题