登录状态管理：JWT、Session 与 Token 策略
- Henry Wei
- 发布于 2天前
- 阅读 102
本章解析了 Web3 登录后为何需引入 JWT 管理登录态，讲解其结构、签发与校验机制，并对比 Web2 的 Session 模型。前端使用 Zustand 持久化状态，后端验签生成 JWT，实现完整的身份生命周期管理
📚 作者：Henry 🧱 系列：《Web2 到 Web3：登录与身份验证机制全面进化》 · 第 5 篇 👨💻 受众：Web2 & Web3 开发者 / 区块链学习者 👉 系列持续更新中，建议收藏专栏或关注作者
🧩 登录后的状态问题：Web2 vs Web3 的差异
| 问题 | Web2 答案 | Web3 答案 |
|---|---|---|
| 登录后怎么识别用户？ | Cookie / Session ID | 钱包地址 + JWT |
| 状态存哪里？ | 服务器 Session Store | 前端存 JWT（localStorage / Zustand） |
| Token 从哪来？ | 登录接口签发 | 签名验证后后端签发 |
| Token 多久有效？ | 可配置 TTL | 一般 10~30 分钟 |
🧾 为什么 Web3 仍需要 JWT？
虽然用户登录动作通过签名完成，但如果每个 API 都重复要求签名，会带来：
- 签名频繁（用户体验差）
- 钱包弹窗干扰（安全隐患）
- API 无法统一识别登录态
✅ 因此需要：一次签名 → 签发 JWT → 后续所有请求用 JWT 识别身份
🧠 JWT 与签名的角色分工
| 阶段 | 工具 | 说明 |
|---|---|---|
| 登录动作 | 签名（EIP-712） | 用户证明自己控制该地址（一次） |
| 登录状态 | JWT / accessToken | 后端基于签名结果生成，携带身份 |
| 接口访问 | ... |
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。
