构图AI

JWT 登录架构

JWT + Redis 登录架构怎么画？这篇指南梳理核心元素、常见结构、手动画图与 AI 生成的差异，并附 prompt 模板，帮助你在架构评审和文档中快速画出可用的 JWT 登录架构图。

作者：松柏

JWT 登录架构

JWT + Redis 登录架构图应画出客户端、网关、鉴权服务、业务服务、Redis 与用户库，并区分登录签发、业务验票与 Refresh 续期三条链路。

JWT（JSON Web Token）+ Redis 是当前 Web 后端最主流的登录与会话保持方案之一。客户端用凭证换取短 Access Token + 长 Refresh Token，后端把会话或黑名单放进 Redis，后续请求校验签名并查缓存，天然适合分布式部署。这篇指南梳理核心元素、常见结构、手动画图与 AI 生成的差异，并给出可直接复制到 构图AI 的 prompt。

构图AI 一句话生成手绘风格技术图，基于 Excalidraw 可编辑，支持 PNG / SVG / .excalidraw 导出；内置 12 种图类型与约 25 个示例，含 JWT / 登录相关模板。

何时需要画一张 JWT 架构图

  • 架构评审：说明客户端、网关、鉴权服务、业务服务、Redis 各自职责。
  • 新人 onboarding：讲清 Token 如何签发、校验与失效。
  • 技术文档配图：放进 PRD / API 文档 / 事故复盘。
  • 跨团队沟通：与前端、运维、安全对齐续期、登出、密钥轮换。
  • 安全审计：展示黑名单、短 TTL、Refresh 存储位置等控制点。

核心元素

一张合格的 JWT 登录架构图至少要包含：

  1. 客户端（Client）：浏览器或 App，发起登录并持有 Token。
  2. 网关 / 反向代理（Gateway）：统一入口，做基础校验或转发。
  3. 鉴权服务（Auth Service）：核凭证、签发 Access / Refresh Token。
  4. 业务服务（Business Service）：凭有效 Token 提供业务能力。
  5. Redis：缓存会话 / Token 元数据 / 黑名单。
  6. 数据库（User DB）：持久化账号与密码哈希。

连接关系上要清晰表达：

  • 登录链路：Client → Gateway → Auth → DB 校验 → 写 Redis → 返回双 Token。
  • 业务请求：Client → Gateway → Business → Redis（校验有效性）。
  • 续期链路：Client → Gateway → Auth → Redis 校验 Refresh → 重新签发。

手动画图 vs AI 生成

维度手动画（draw.io / PPT）AI 生成（构图AI）
耗时15–40 分钟约 5–10 秒出草稿
修改成本拖拽改线一句话微调或画布手改
风格统一性看画的人默认手绘风
适用场景对外终稿草稿、文档配图、评审
导出视工具而定PNG / SVG / .excalidraw

实际工作中，先 AI 生成草稿再手改 效率最高。架构评审前用 AI 出一张，开会对着图讨论，比口头描述快得多。登录后有 1 次免费额度；VIP 不限制 AI 画图，适合安全评审多轮改稿。

用构图AI 怎么画

打开 画图页，粘贴下面 prompt（也可套用 JWT 示例）：

画一张 JWT + Redis 登录架构图，手绘风。
节点：客户端、网关、鉴权服务、业务服务、Redis、用户数据库。
登录链路：客户端 → 网关 → 鉴权服务 → 用户数据库（校验密码）→ Redis（写入 Token）→ 返回 Access Token + Refresh Token 给客户端。
业务请求链路：客户端带着 Access Token → 网关 → 业务服务 → Redis（校验）→ 返回业务结果。
Refresh 链路：Access Token 过期后，客户端用 Refresh Token 走鉴权服务重新签发。

如果节点太多，可追加：「去掉业务服务，只画登录链路」。生成后重点检查：三条链路颜色或标签是否可区分；Redis 是否同时出现在「写」与「读」路径。

行业变体

  • 多端登录：增加设备指纹 / 会话列表节点，限制同账号并发。
  • SSO 单点登录：鉴权抽成独立 SSO，多业务共用，图上增加「业务 A / B」回调。
  • 小程序登录：凭证从账密换成微信 code，详见 微信登录示例。
  • OAuth2 第三方登录：增加 IdP（Google / GitHub），详见 OAuth 流程示例。

也可把架构图与 时序图入门 组合：架构定边界，时序定一次调用的先后。12 种技能里架构图与时序图分开用，比硬塞一张更清晰。

实践注意（可画进注释）

  • Access Token TTL 常见 15–30 分钟；高安全场景更短。
  • Refresh Token 社区常见存 HttpOnly Cookie + Secure。
  • 登出 = 删 Redis 会话或加黑名单，不只是前端清本地。
  • 密钥轮换要在图注标明「验签支持多 kid」。

这些细节不必全部画成节点，用注释框点到即可，避免架构图变成安全白皮书。

安全评审时怎么讲这张图

拿着 JWT 架构图做安全评审时，建议主动引导三个问题，而不是只展示「我们用了 JWT」：

  1. 机密落点：签名密钥存在哪、如何轮换、是否多实例共享？
  2. 失效模型：登出、改密、封禁用户后，旧 Access Token 多久失效？靠短 TTL 还是黑名单？
  3. 传输与存储：浏览器里 Access Token 放内存还是 localStorage？Refresh 是否 HttpOnly？

把答案写成图注，比临时口头补充更不容易在复盘时丢失。若系统已是微服务，还需标明：网关验签还是各服务本地验签、是否存在「内网免鉴权」的隐式信任。隐式信任不是不能有，但必须画出来，否则新人会误以为所有路径都同等安全。

与 登录流程图 分工：流程讲「用户怎么进来」，本图讲「进来之后凭证如何流转」。两张图都导出 PNG 放进同一份安全说明，阅读成本最低。

若你们使用网关统一验签，请在图上明确「业务服务是否仍二次校验」。只验一次可以，但必须写清信任边界；什么都不写时，安全评审往往会默认最坏情况并要求补控。密钥管理、时钟同步（JWT 的 exp 对时钟敏感）也可以各用一行注释带过，不必单独画成子系统。多人协作维护认证文档时，约定「改代码必改图」比事后补画更不容易出现文档漂移。也可以把常见攻击面（Token 窃取、Refresh 重放）写成图外附录，架构图本身保持干净，需要时再链到安全专项说明。完成图后请让前端同学确认 Token 存储描述与实现一致，这是最容易各说各话的地方。安全与研发对过一次口径后，再把 PNG 固化进仓库文档目录。

相关指南

常见问题

JWT 登录架构图至少要包含哪些节点？+

至少包含客户端、网关、鉴权服务、业务服务、Redis、用户数据库。并分别画出登录签发、业务验票、Refresh 续期三条链路，否则评审时容易只看到「有个 Token」而看不清校验发生在哪。

Access Token 和 Refresh Token 在图上怎么区分？+

用不同颜色或标签标注两种 Token；登录响应同时返回两者，业务请求只带 Access Token，过期后续期链路只走 Refresh → 鉴权服务 → Redis。不要把两种 Token 画成同一条箭头。

Redis 挂了时，架构图要不要画降级路径？+

对内架构评审建议画：例如「本地验签 + DB 黑名单兜底」。对外简介图可省略，但需在注释写明可用性假设，避免被误认为 Redis 是单点且无预案。

JWT 架构图和登录时序图怎么配合使用？+

架构图展示组件与存储关系；时序图展示一次登录 / 续期的消息顺序。评审时先投架构图对齐边界，再用时序图抠细节。

相关指南