企业认证与安全体系（十）：一张图看懂企业认证架构——从登录、鉴权到权限控制完整串联

上一篇我们讲了：

《企业认证与安全体系（九）：单点登录 SSO 到底是怎么实现的？一篇讲透企业统一身份认证》

到这里，这个系列已经讲完了企业认证体系中的核心知识点：

双 Token Token + Redis JWT Spring Security Gateway OAuth2 RBAC SSO

如果单独看每一篇，可能只是一个个知识点。

但是在真实企业项目里，它们不是孤立存在的，而是共同组成了一套完整的认证与授权体系。

这篇作为整个系列的收官篇，我们不再展开某一个单点，而是从全局视角，把前面九篇全部串起来。

真正回答一个问题：

企业里的登录认证体系到底是怎么设计的？

一、先看完整架构图

一个典型企业认证体系，大概可以抽象成下面这张图：

用户 ↓ 客户端：Web / APP / 小程序 ↓ 登录请求 ↓ 统一认证服务 / Spring Security ↓ 账号密码认证 / 第三方登录 / SSO ↓ 生成 AccessToken + RefreshToken ↓ JWT 表达身份 ↓ Redis 管理会话 ↓ 返回客户端 ↓ 客户端携带 Token 请求接口 ↓ Gateway 统一鉴权 ↓ JWT 校验 ↓ Redis 会话检查 ↓ 加载用户权限 ↓ RBAC 权限判断 ↓ 业务服务

如果用一句话总结：

Spring Security 负责认证框架，JWT 负责身份表达，Redis 负责会话控制，Gateway 负责统一入口，RBAC 负责权限判断，OAuth2 / SSO 负责第三方和多系统统一身份。

二、先从最基础的问题开始：用户怎么登录？

企业认证体系的起点一定是登录。

登录方式一般有几种：

账号密码登录 手机号验证码登录 微信 / GitHub / 企业微信登录 统一认证中心 SSO 登录

不管是哪一种登录方式，最终目的都是一样的：

确认当前用户是谁。

例如：

userId = 1001 username = zhangsan

这一步叫认证。

认证解决的是：

你是谁

前面第一篇到第三篇，本质上都在围绕“用户登录后如何维护身份”展开。

三、为什么需要双 Token？

如果用户登录成功后，只返回一个 Token，会有什么问题？

如果 Token 有效期太短，用户频繁掉登录。

如果 Token 有效期太长，Token 泄露后风险很大。

所以企业里通常采用双 Token 机制：

AccessToken 用于访问接口。

RefreshToken 用于 AccessToken 过期后的自动续签。

这样既保证了安全性，也保证了用户体验。

所以第一篇的核心就是：

双 Token 解决的是安全和体验之间的平衡问题。

四、为什么企业喜欢 Token + Redis？

很多人刚开始学认证，容易觉得 JWT 就够了。

但真实企业里经常会使用：

Token + Redis

或者：

JWT + Redis

原因很简单：

企业真正关心的不是无状态，而是可控。

JWT 的问题是：

只要没有过期，就很难主动失效

但是企业系统需要：

主动踢下线 账号冻结 单设备登录 多端控制 注销立即失效 风险设备拦截

这些能力都需要服务端可控。

Redis 正好适合做这件事。

例如：

login:user:1001 -> 当前登录状态 refresh:user:1001 -> RefreshToken token:blacklist:xxx -> Token 黑名单

所以第二篇的核心就是：

Redis 是企业认证体系中的会话控制中心。

五、JWT 到底负责什么？

JWT 本质上是一种 Token 格式。

它的特点是：

自带用户信息 可以验签 不可随意篡改 服务端可以本地校验

一个 JWT 通常由三部分组成：

Header.Payload.Signature

它解决的问题是：

如何用一个 Token 表达用户身份。

例如 JWT 中可以放：

{ "userId": 1001, "username": "zhangsan", "role": "ADMIN", "exp": 1711111111 }

但要注意：

JWT 不是加密，只是编码加签。

所以 JWT 里不能放密码、身份证、银行卡等敏感信息。

第三篇的核心就是：

JWT 负责身份表达，但不负责完整的会话生命周期管理。

六、Spring Security 在体系里做什么？

Spring Security 很多人一开始会觉得难。

其实它在企业认证体系中的定位很清楚：

Spring Security 是认证与授权框架。

它负责把认证流程规范化。

例如：

请求进入系统 ↓ Security Filter Chain ↓ JwtAuthenticationFilter ↓ 解析 Token ↓ 创建 Authentication ↓ 放入 SecurityContextHolder

几个核心概念要记住：

第五篇的核心就是：

Spring Security 把登录认证、Token 校验、用户上下文、权限判断统一组织起来。

七、一次真实登录链路是怎样的？

真实企业项目里，一次账号密码登录大概是这样：

用户输入账号密码 ↓ POST /login ↓ Spring Security 认证用户名密码 ↓ 认证成功 ↓ 查询用户信息 ↓ 查询角色和权限 ↓ 生成 AccessToken ↓ 生成 RefreshToken ↓ RefreshToken 存入 Redis ↓ 返回客户端

返回结果一般是：

{ "accessToken": "xxx", "refreshToken": "yyy" }

客户端保存 Token。

后续访问接口时，在请求头中携带：

Authorization: Bearer xxx

这就是企业登录链路的基础。

八、一次接口请求链路是怎样的？

登录成功后，用户访问接口。

例如：

GET /order/list

请求链路通常是：

客户端携带 AccessToken ↓ Gateway ↓ JwtAuthenticationFilter ↓ 校验 JWT 签名 ↓ 判断 JWT 是否过期 ↓ 查询 Redis 会话状态 ↓ 加载用户权限 ↓ 写入 SecurityContextHolder ↓ 进入 Controller ↓ 执行业务逻辑

如果 JWT 过期：

返回 401

如果 Redis 中会话不存在：

说明用户被踢下线或登录态失效 返回 401

如果权限不足：

返回 403

这里要区分：

这是企业接口鉴权中非常重要的区别。

九、AccessToken 过期后怎么办？

AccessToken 通常有效期较短。

例如：

30 分钟 2 小时

当 AccessToken 过期后，客户端请求接口会收到：

401 Unauthorized

这时候客户端会用 RefreshToken 调用刷新接口：

POST /refresh

服务端会检查 Redis 中保存的 RefreshToken。

如果 RefreshToken 合法且未过期：

生成新的 AccessToken 返回客户端 客户端重试原请求

如果 RefreshToken 也过期：

用户必须重新登录

所以 RefreshToken 的作用是：

在用户登录态仍然有效的情况下，无感刷新 AccessToken。

十、强制下线是怎么实现的？

很多人会问：

JWT 不是没过期就有效吗？

那怎么踢下线？

答案就是 Redis。

假设 Redis 中有：

login:user:1001 -> valid

管理员点击踢下线时，服务端删除：

login:user:1001

用户下次请求时：

JWT 验签成功 ↓ Redis 会话检查失败 ↓ 返回 401

这样即使 JWT 还没过期，也无法继续访问系统。

这就是为什么企业项目里经常会使用 Redis。

因为 Redis 让登录态变得可控。

十一、Gateway 为什么能统一鉴权？

在单体应用中，请求直接进入 Spring Boot 应用。

但是在微服务架构中，后面可能有很多服务：

用户服务 订单服务 商品服务 支付服务 消息服务

如果每个服务都自己校验 Token，会出现大量重复代码。

所以企业里通常会使用 Gateway 做统一入口。

流程是：

客户端请求 ↓ Gateway ↓ JWT 校验 ↓ Redis 会话检查 ↓ 解析用户信息 ↓ 将用户信息写入 Header ↓ 转发到业务服务

例如 Gateway 可以向后端服务传递：

X-User-Id: 1001 X-User-Name: zhangsan X-Role: ADMIN

业务服务就不需要重复解析 JWT。

第六篇的核心就是：

Gateway 负责把认证逻辑前置到统一入口，业务服务专注业务。

十二、RBAC 在什么时候发挥作用？

前面说的都是认证：

你是谁

但企业系统还必须解决授权：

你能干什么

这就是 RBAC。

RBAC 的核心模型是：

用户 ↓ 角色 ↓ 权限

例如：

张三 ↓ 运营角色 ↓ order:list、order:detail、product:update

一个基础的 RBAC 通常有五张表：

sys_user sys_role sys_permission sys_user_role sys_role_permission

登录时，系统会加载用户权限集合：

[ "order:list", "order:detail", "order:export" ]

接口上可以用权限注解控制：

@PreAuthorize("hasAuthority('order:export')") @PostMapping("/order/export") public void exportOrder() { // 导出订单 }

这一步解决的是：

当前用户有没有资格执行这个操作。

十三、菜单权限、按钮权限、接口权限怎么配合？

企业后台常见权限包括：

菜单权限 按钮权限 接口权限 数据权限

菜单权限控制：

用户能不能看到某个菜单

按钮权限控制：

用户能不能看到或点击某个按钮

接口权限控制：

用户能不能调用某个后端接口

数据权限控制：

用户能看到哪些数据

这里必须记住一句话：

前端控制显示，后端控制安全。

前端隐藏按钮只是用户体验。

真正的安全一定要在后端接口做权限校验。

因为用户可以绕过前端，直接请求接口。

十四、OAuth2 在体系中解决什么问题？

OAuth2 不是用来替代 JWT 的。

OAuth2 解决的是：

第三方授权问题。

例如：

微信登录 GitHub 登录 企业微信登录 钉钉登录 Google 登录

用户不应该把第三方平台的账号密码交给你的系统。

所以 OAuth2 的思路是：

用户跳转到第三方平台登录 ↓ 用户同意授权 ↓ 第三方平台返回 code ↓ 你的后端用 code 换 AccessToken ↓ 你的后端获取用户信息 ↓ 你的系统创建或绑定本地用户 ↓ 你的系统签发自己的 Token

这里要注意：

第三方平台的 Token，不等于你系统自己的 Token。

第三方 Token 用于访问第三方资源。

你系统自己的 Token 用于访问你自己的业务系统。

十五、SSO 在体系中解决什么问题？

SSO 解决的是多系统统一登录问题。

它的核心目标是：

用户登录一次 可以访问多个相互信任的系统

例如：

OA CRM ERP 财务系统 工单系统

用户不需要每个系统都登录一次。

SSO 的核心是统一认证中心。

流程大概是：

用户访问系统 A ↓ 系统 A 发现未登录 ↓ 跳转统一认证中心 ↓ 用户完成登录 ↓ 认证中心返回认证结果 ↓ 系统 A 建立登录态 用户访问系统 B ↓ 系统 B 跳转认证中心 ↓ 认证中心发现用户已登录 ↓ 直接返回认证结果 ↓ 系统 B 建立登录态

所以第九篇的核心是：

SSO 把登录能力从各个业务系统中抽离出来，交给统一认证中心。

十六、完整认证体系中的职责分工

到这里，我们可以把整个系列的知识点做一个总表。

这些技术不是谁替代谁，而是各自解决不同层面的问题。

十七、企业认证体系的完整流程

最后，我们把登录、鉴权、授权、续签、下线全部串起来。

1. 登录阶段

用户输入账号密码 ↓ Spring Security 认证 ↓ 查询用户角色权限 ↓ 生成 AccessToken ↓ 生成 RefreshToken ↓ Redis 保存会话 ↓ 返回客户端

2. 接口访问阶段

客户端携带 AccessToken ↓ Gateway 接收请求 ↓ JWT 校验 ↓ Redis 会话检查 ↓ RBAC 权限判断 ↓ 转发业务服务 ↓ 执行业务逻辑

3. Token 续签阶段

AccessToken 过期 ↓ 接口返回 401 ↓ 客户端调用 refresh 接口 ↓ 服务端校验 RefreshToken ↓ 生成新的 AccessToken ↓ 客户端重试原请求

4. 强制下线阶段

管理员踢用户下线 ↓ 删除 Redis 登录态 ↓ 用户再次请求接口 ↓ JWT 验签成功 ↓ Redis 校验失败 ↓ 返回 401

5. 权限判断阶段

用户请求接口 ↓ 系统获取用户权限集合 ↓ 判断是否拥有接口权限 ↓ 有权限：放行 ↓ 无权限：返回 403

6. 第三方登录阶段

用户点击微信登录 ↓ 跳转微信授权 ↓ 微信返回 code ↓ 后端用 code 换用户信息 ↓ 本系统创建或绑定用户 ↓ 本系统签发自己的 Token

7. SSO 登录阶段

用户访问业务系统 ↓ 业务系统跳转认证中心 ↓ 认证中心完成登录 ↓ 返回认证结果 ↓ 业务系统建立登录态 ↓ 用户访问其他系统时无需重复输入账号密码

十八、为什么这套体系是企业级的？

因为它不是只解决“能不能登录”。

它解决的是完整的会话生命周期。

包括：

登录 认证 鉴权 授权 续签 过期 踢下线 单设备登录 多端控制 权限管理 第三方登录 统一身份认证

这才是企业级认证体系和普通 Demo 的区别。

普通 Demo 可能只是：

登录成功 返回 Token

而企业系统要考虑：

Token 泄露怎么办？ 用户离职怎么办？ 账号冻结怎么办？ 权限变更怎么办？ 多个系统怎么统一登录？ 多个服务怎么统一鉴权？ 前端按钮隐藏了，后端接口安全吗？ RefreshToken 过期怎么办？

所以企业认证体系本质上解决的是：

身份、会话、权限、系统边界之间的协同问题。

十九、这个系列的完整目录

最后回顾一下整个系列。

第一篇：为什么企业都在用双 Token 机制？

讲清楚 AccessToken、RefreshToken，以及为什么 RefreshToken 也会过期。

第二篇：为什么很多企业放弃纯 JWT，而选择 Token + Redis？

讲清楚 JWT 的优势和缺陷，以及 Redis 为什么适合做会话控制。

第三篇：一篇讲透 JWT 原理与企业级实践

讲清楚 Header、Payload、Signature、签名、防篡改、不能存敏感信息。

第四篇：企业登录认证流程全解析——JWT、Redis、Spring Security 如何协同工作？

讲清楚登录、接口访问、自动续签、强制下线的完整链路。

第五篇：Spring Security + JWT + Redis 企业级认证实战

讲清楚 SecurityConfig、JwtFilter、Authentication、SecurityContextHolder、Redis 的实战结构。

第六篇：Gateway 为什么能统一鉴权？一篇讲透微服务认证体系

讲清楚微服务下为什么要把鉴权前置到 Gateway。

第七篇：OAuth2 到底解决了什么问题？一篇讲透授权与第三方登录

讲清楚 OAuth2 不是单纯登录，而是第三方授权。

第八篇：企业为什么都在用 RBAC？一篇讲透权限模型设计

讲清楚用户、角色、权限、菜单权限、按钮权限、接口权限和数据权限。

第九篇：单点登录 SSO 到底是怎么实现的？一篇讲透企业统一身份认证

讲清楚多个系统如何共用统一认证中心。

第十篇：一张图看懂企业认证架构——从登录、鉴权到权限控制完整串联

也就是本文，把前面所有内容串成完整体系。

二十、最终核心理解

这个系列最重要的不是记住某个框架 API。

而是建立一套完整认知：

认证：你是谁 授权：你能干什么 会话：你的登录态是否还有效 网关：请求从哪里统一进入 权限：你能操作哪些功能 SSO：多个系统如何统一登录 OAuth2：第三方如何安全授权 Redis：服务端如何主动控制会话 JWT：Token 如何表达身份

当你理解了这套关系，再去看：

Spring Security OAuth2 Gateway JWT Redis RBAC SSO

就不会觉得它们是零散知识点。

你会发现，它们其实都在围绕一个核心目标服务：

让企业系统安全、可控、统一地识别用户，并控制用户能访问什么。

这就是企业认证与安全体系的真正价值。

结语

到这里，《企业认证与安全体系》这个系列就完整收官了。

从双 Token 到 Token + Redis，从 JWT 到 Spring Security，从 Gateway 到 OAuth2，从 RBAC 到 SSO，我们一步步把企业认证体系串成了一条完整链路。

如果只看单点知识，可能每个技术都不算特别难。

但真正有价值的是：

把这些技术放回企业项目中，理解它们为什么出现、解决什么问题、彼此如何协作。

这也是工程能力和架构能力的区别。

框架只是工具。

真正重要的是：

你能不能从系统视角理解整个认证体系。