RBAC、ACL、ABAC、JWT 完整原理业务流程落地对比一、前置基础鉴权两大核心概念认证 Authentication你是谁登录、验证身份JWT主要做这件事授权 Authorization你能做什么ACL/RBAC/ABAC解决权限管控认证是授权的前置步骤流程统一登录生成凭证→接口携带凭证→校验身份→再校验访问权限。二、ACL 访问控制列表Access Control List1. 核心定义直接绑定用户-资源权限给每个资源维护一张访问名单名单里写死哪些用户能操作。2. 数据模型用户ID | 资源ID | 操作权限(read/write/delete) 1001 | order | read 1001 | user | write 1002 | goods | read3. 完整执行流程用户登录拿到身份标识 userId请求接口携带userId 访问资源标识接口/页面/文件后端查询ACL表匹配userId资源是否存在权限记录存在则放行不存在返回403无权限4. 优缺点优点逻辑极简小型单机系统快速实现细粒度资源管控精准控制单用户单资源致命缺点用户多、资源多数据爆炸1000用户1000资源产生百万级关联数据批量权限修改极麻烦比如新增10个管理员需要逐条插入上千条权限记录无复用性权限不能批量分配几乎不用于中大型后台5. 适用场景单机小型工具、文件服务器、简单内部管理系统三、RBAC 基于角色的访问控制Role-Based Access Control1. 行业现状目前90%企业后台、管理系统默认方案引入「角色」做中间层解耦用户和权限。三层模型用户 ↔ 角色 ↔ 权限2. 细分标准RBAC0~RBAC4RBAC0基础版用户多角色角色多权限最常用RBAC1支持角色分层超级管理员 部门管理员 普通员工RBAC2支持角色互斥、时间权限约束RBAC3 RBAC1RBAC2完整企业级方案3. 数据库表设计标准5张表用户表 user(id,name,pwd)角色表 role(id,role_name,desc)用户角色关联 user_role(user_id,role_id) 多对多权限表 permission(id,resource,operation) 接口/按钮/菜单权限角色权限关联 role_permission(role_id,perm_id) 多对多4. 完整业务执行流程用户账号密码登录校验账号密码正确根据 userId 查询所有绑定角色根据角色批量查询该角色下全部权限标识order:list、user:add后端生成权限集合存入缓存/会话同时下发JWT携带角色信息用户请求业务接口携带JWT令牌第一步解析JWT获取userId、角色列表第二步获取当前接口需要的权限标识第三步对比用户权限集合是否包含接口所需权限包含放行执行业务不包含返回403权限不足5. 示例业务场景角色运营管理员、财务、超级管理员给运营角色分配商品查看、订单查询权限新增运营员工只需绑定「运营管理员」角色自动继承全部权限6. 优缺点优点权限批量管理新增用户只分配角色维护成本极低表结构清晰缓存友好查询性能高适配单体、微服务、多租户绝大多数场景缺点无法实现动态细粒度管控只能控制“能不能访问接口”无法区分数据范围比如同是销售角色A只能看自己客户B看全公司客户需搭配数据权限扩展无法基于环境、时间、设备做动态限制四、ABAC 基于属性的访问控制Attribute-Based Access Control1. 核心定义不依赖角色通过多维度属性动态计算权限是云原生、微服务、多租户、复杂权限场景高级方案。三大属性分类用户属性部门、职级、岗位、用户ID、租户ID资源属性数据归属人、资源分类、密级环境属性访问时间、IP地址、客户端设备、请求渠道2. 核心逻辑策略匹配编写权限策略规则运行时提取三方属性代入规则规则满足则授权。规则示例if (用户.部门 销售部) AND (资源.归属租户 当前用户租户) AND (访问时间 9:00-18:00) 允许查看客户数据 else 拒绝访问3. 完整执行流程用户登录JWT携带用户全部属性部门、租户、职级等请求资源时后端同时获取用户属性解析JWT被访问资源属性数据库查询数据归属环境属性当前时间、请求IP加载预定义ABAC策略规则引擎将三类属性传入规则引擎做布尔运算引擎返回允许/拒绝完成授权4. 优缺点优点极致动态、细粒度数据权限天然支持行级数据隔离无需频繁维护角色规则配置化后台可视化修改策略无需改代码天然适配多租户、云平台、风控系统、金融级权限管控缺点实现复杂需要规则引擎Open Policy Agent OPA计算逻辑重相比RBAC性能损耗更高中小后台系统过度设计维护成本高5. 适用场景金融系统、多租户SaaS平台、云资源管控、政府分级涉密系统五、JWT 无状态认证令牌JSON Web Token1. 作用定位ACL/RBAC/ABAC是授权方案JWT是跨服务身份认证载体用来在微服务、前后端分离系统传递用户身份、角色、属性信息。2. JWT三段结构Base64编码非加密Header 头部加密算法HS256/RS256、令牌类型Payload 载荷核心存放自定义业务数据标准字段exp过期时间、iss签发方、sub用户ID自定义字段roles:[admin,finance]、tenantId、deptABAC所需属性全部放这里Signature 签名密钥加密头部载荷防止篡改3. JWT 完整登录鉴权全流程前后端分离/微服务通用步骤1用户登录获取JWT前端提交账号密码到登录接口后端校验账号密码查询用户角色/属性组装JWT载荷userId、roles、租户ID、部门、过期时间使用密钥生成签名拼接三段生成完整JWT字符串返回JWT给前端前端存储localStorage/cookie步骤2前端携带令牌请求所有业务接口每次HTTP请求Header自动携带Authorization: Bearer {JWT字符串}步骤3网关/拦截器统一校验JWT微服务推荐网关校验拦截器提取Header中的JWT使用服务端密钥校验签名签名篡改 → 直接返回401令牌非法校验通过 → 解码Payload提取用户身份、角色、属性校验exp过期时间过期返回401重新登录将解码后的用户信息存入上下文向下传递给授权模块步骤4授权模块执行ACL/RBAC/ABAC权限校验根据解码出来的用户信息执行对应权限逻辑判断是否放行接口。步骤5JWT刷新机制解决短期过期AccessToken短期有效30分钟用于业务鉴权RefreshToken长期有效7天存在数据库绑定用户Access过期后前端携带RefreshToken调用刷新接口后端校验RefreshToken合法下发新AccessToken4. JWT优缺点优点无状态服务端不存储会话分布式微服务无需共享Session自包含载荷自带角色、属性不用频繁查数据库获取用户信息跨域、跨服务友好适配前后端分离、网关架构缺点无法主动失效令牌未过期前用户退出登录仍可使用解决方案Redis黑名单、短过期时间载荷不能存敏感数据仅Base64编码可直接解码查看令牌体积大每次请求携带增加网络开销六、ACL vs RBAC vs ABAC 横向对比表维度ACLRBACABAC核心绑定关系用户-资源直连用户-角色-权限用户/资源/环境多属性规则维护难度极高批量修改麻烦低角色批量分配中等配置规则引擎细粒度接口级无数据区分接口级需扩展实现数据权限天然支持行级数据权限动态能力静态写死无法动态约束静态角色仅固定权限集合动态规则时间、IP、租户性能中等最优缓存友好较差规则计算耗时适用系统规模小型单机工具绝大多数中后台管理系统SaaS多租户、金融、云平台配套JWT适配适配载荷存userId完美适配载荷存roles完美适配载荷存全量用户属性七、企业通用落地组合方案生产环境推荐方案1中小型后台管理系统90%项目选用RBAC JWTJWT携带userId、角色列表拦截器解析JWT基于RBAC校验菜单、按钮、接口权限数据范围权限扩展在RBAC基础上增加用户数据归属字段方案2多租户SaaS、金融复杂权限系统ABAC JWT OPA规则引擎JWT存放用户部门、租户、职级等全部属性网关解析JWT后传入OPA引擎执行ABAC策略可视化后台配置权限规则无需修改代码方案3简单内部工具、文件服务器ACL JWT轻量化实现用户量少场景够用八、Mermaid 核心流程图可直接复制到CSDN渲染1. RBACJWT完整鉴权流程失败成功无有前端登录提交账号密码后端校验账号密码查询用户绑定角色权限组装载荷userId、roles、exp密钥签名生成JWT前端存储JWT业务请求携带Authorization:Bearer JWT网关拦截器校验JWT签名过期校验通过?返回401未认证解码获取userId、角色集合RBAC校验接口所需权限拥有权限?返回403禁止访问执行业务逻辑返回数据2. ABAC 授权逻辑流程图否是解析JWT获取用户属性查询数据库获取资源属性获取请求环境属性IP、时间、设备传入OPA规则引擎执行ABAC布尔策略规则规则匹配成功?403权限拒绝放行访问资源九、总结ACL是最原始权限模型仅小型工具使用RBAC是通用标准权限方案开发成本低、性能好绝大多数后台首选ABAC面向复杂动态权限场景依赖规则引擎适合多租户、金融系统JWT是认证载体和三种授权模型可以任意组合解决分布式系统身份传递问题生产落地优先选择 RBAC JWT 组合复杂SaaS平台升级为 ABAC JWT OPA。