Token 认证

用户登录成功后，服务端需要一种方式让后续请求证明“这是同一个已登录用户”。Token 就是这种凭证。

常见设计有两类：不透明 Token 和 JWT。

不透明 Token

不透明 Token 本身没有业务含义，只是一个随机字符串：

token = random(256bit)

服务端把 token 和用户、会话、过期时间存在数据库或缓存里。每次请求带上 token，服务端查存储确认身份。

优点是容易撤销、容易控制；缺点是每次请求都需要查询服务端状态。

JWT

JWT 把用户身份和过期时间写进 Token，并用签名防篡改：

配置要点

• 配置表达的是环境差异和运行参数，不是业务规则本身。

服务端验证签名即可识别用户，不一定需要查数据库。优点是适合分布式系统和跨服务传递；缺点是撤销困难，签发后在过期前通常仍然有效。

Access Token 与 Refresh Token

生产系统通常拆成两个 Token：

• Access Token：有效期短，用于访问 API。
• Refresh Token：有效期长，用于换取新的 Access Token。

这样即使 Access Token 泄露，风险窗口也较短；Refresh Token 则需要更严格保护，例如绑定设备、轮换、可撤销。

Token 存放位置

Web 场景常见两种方式：

• Cookie：配合 HttpOnly、Secure、SameSite，降低 XSS 读取风险。
• LocalStorage：实现简单，但更容易被 XSS 窃取。

如果使用 Cookie，还要考虑 CSRF；如果使用 Authorization Header，还要重点防 XSS。没有绝对安全的存放方式，关键是理解威胁模型。

设计取舍

Token 设计要回答四个问题：

• 是否需要随时撤销？
• 是否需要跨服务离线验证？
• Token 泄露后的风险窗口多长？
• 客户端是浏览器、移动端还是服务端？

下一章会进入会话管理，处理 Token 背后的登录态、设备、续期和撤销问题。