:一张图看懂企业认证架构——从登录、鉴权到权限控制完整串联)
上一篇我们讲了《企业认证与安全体系九单点登录 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 机制Token作用有效期AccessToken访问接口短RefreshToken刷新 AccessToken长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几个核心概念要记住概念作用Filter Chain请求进入 Controller 前的过滤器链Authentication当前认证用户SecurityContextHolder保存当前用户上下文OncePerRequestFilter保证一次请求只执行一次过滤逻辑UserDetails用户详情GrantedAuthority用户权限第五篇的核心就是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这里要区分状态码含义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 把登录能力从各个业务系统中抽离出来交给统一认证中心。十六、完整认证体系中的职责分工到这里我们可以把整个系列的知识点做一个总表。模块解决的问题Session早期服务端会话方案Token前后端分离下的身份凭证双 Token安全和体验的平衡AccessToken访问接口RefreshToken刷新 AccessTokenJWTToken 身份表达Redis会话控制和主动失效Spring Security认证授权框架Gateway微服务统一鉴权入口RBAC权限模型OAuth2第三方授权OIDC第三方身份认证SSO多系统统一登录这些技术不是谁替代谁而是各自解决不同层面的问题。十七、企业认证体系的完整流程最后我们把登录、鉴权、授权、续签、下线全部串起来。1. 登录阶段用户输入账号密码 ↓ Spring Security 认证 ↓ 查询用户角色权限 ↓ 生成 AccessToken ↓ 生成 RefreshToken ↓ Redis 保存会话 ↓ 返回客户端2. 接口访问阶段客户端携带 AccessToken ↓ Gateway 接收请求 ↓ JWT 校验 ↓ Redis 会话检查 ↓ RBAC 权限判断 ↓ 转发业务服务 ↓ 执行业务逻辑3. Token 续签阶段AccessToken 过期 ↓ 接口返回 401 ↓ 客户端调用 refresh 接口 ↓ 服务端校验 RefreshToken ↓ 生成新的 AccessToken ↓ 客户端重试原请求4. 强制下线阶段管理员踢用户下线 ↓ 删除 Redis 登录态 ↓ 用户再次请求接口 ↓ JWT 验签成功 ↓ Redis 校验失败 ↓ 返回 4015. 权限判断阶段用户请求接口 ↓ 系统获取用户权限集合 ↓ 判断是否拥有接口权限 ↓ 有权限放行 ↓ 无权限返回 4036. 第三方登录阶段用户点击微信登录 ↓ 跳转微信授权 ↓ 微信返回 code ↓ 后端用 code 换用户信息 ↓ 本系统创建或绑定用户 ↓ 本系统签发自己的 Token7. 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服务端如何主动控制会话 JWTToken 如何表达身份当你理解了这套关系再去看Spring Security OAuth2 Gateway JWT Redis RBAC SSO就不会觉得它们是零散知识点。你会发现它们其实都在围绕一个核心目标服务让企业系统安全、可控、统一地识别用户并控制用户能访问什么。这就是企业认证与安全体系的真正价值。结语到这里《企业认证与安全体系》这个系列就完整收官了。从双 Token 到 Token Redis从 JWT 到 Spring Security从 Gateway 到 OAuth2从 RBAC 到 SSO我们一步步把企业认证体系串成了一条完整链路。如果只看单点知识可能每个技术都不算特别难。但真正有价值的是把这些技术放回企业项目中理解它们为什么出现、解决什么问题、彼此如何协作。这也是工程能力和架构能力的区别。框架只是工具。真正重要的是你能不能从系统视角理解整个认证体系。