RBAC、ACL、ABAC、JWT 完整原理+业务流程+落地对比

一、前置基础：鉴权两大核心概念

1. 认证 Authentication：你是谁（登录、验证身份，JWT主要做这件事）
2. 授权 Authorization：你能做什么（ACL/RBAC/ABAC解决权限管控）

认证是授权的前置步骤，流程统一：登录生成凭证→接口携带凭证→校验身份→再校验访问权限。

二、ACL 访问控制列表（Access Control List）

1. 核心定义

直接绑定用户-资源权限，给每个资源维护一张访问名单，名单里写死哪些用户能操作。

2. 数据模型

用户ID | 资源ID | 操作权限(read/write/delete)
1001   | order  | read
1001   | user   | write
1002   | goods  | read

3. 完整执行流程

1. 用户登录拿到身份标识 userId
2. 请求接口携带userId + 访问资源标识（接口/页面/文件）
3. 后端查询ACL表，匹配 userId+资源 是否存在权限记录
4. 存在则放行，不存在返回403无权限

4. 优缺点

优点

• 逻辑极简，小型单机系统快速实现
• 细粒度资源管控，精准控制单用户单资源

致命缺点

• 用户多、资源多数据爆炸，1000用户+1000资源产生百万级关联数据
• 批量权限修改极麻烦：比如新增10个管理员，需要逐条插入上千条权限记录
• 无复用性，权限不能批量分配，几乎不用于中大型后台

5. 适用场景

单机小型工具、文件服务器、简单内部管理系统

三、RBAC 基于角色的访问控制（Role-Based Access Control）

1. 行业现状

目前90%企业后台、管理系统默认方案，引入「角色」做中间层，解耦用户和权限。
三层模型：用户 ↔ 角色 ↔ 权限

2. 细分标准（RBAC0~RBAC4）

• RBAC0（基础版）：用户多角色，角色多权限（最常用）
• RBAC1：支持角色分层（超级管理员 > 部门管理员 > 普通员工）
• RBAC2：支持角色互斥、时间权限约束
• RBAC3 = RBAC1+RBAC2，完整企业级方案

3. 数据库表设计（标准5张表）

1. 用户表 user(id,name,pwd)
2. 角色表 role(id,role_name,desc)
3. 用户角色关联 user_role(user_id,role_id) 多对多
4. 权限表 permission(id,resource,operation) 接口/按钮/菜单权限
5. 角色权限关联 role_permission(role_id,perm_id) 多对多

4. 完整业务执行流程

1. 用户账号密码登录，校验账号密码正确
2. 根据 userId 查询所有绑定角色
3. 根据角色批量查询该角色下全部权限标识（order:list、user:add）
4. 后端生成权限集合存入缓存/会话，同时下发JWT携带角色信息
5. 用户请求业务接口，携带JWT令牌
6. 第一步：解析JWT获取userId、角色列表
7. 第二步：获取当前接口需要的权限标识
8. 第三步：对比用户权限集合是否包含接口所需权限
   • 包含：放行执行业务
   • 不包含：返回403权限不足

5. 示例业务场景

• 角色：运营管理员、财务、超级管理员
• 给运营角色分配：商品查看、订单查询权限
• 新增运营员工，只需绑定「运营管理员」角色，自动继承全部权限

6. 优缺点

优点

1. 权限批量管理，新增用户只分配角色，维护成本极低
2. 表结构清晰，缓存友好，查询性能高
3. 适配单体、微服务、多租户绝大多数场景

缺点

1. 无法实现动态细粒度管控，只能控制“能不能访问接口”
2. 无法区分数据范围：比如同是销售角色，A只能看自己客户，B看全公司客户（需搭配数据权限扩展）
3. 无法基于环境、时间、设备做动态限制

四、ABAC 基于属性的访问控制（Attribute-Based Access Control）

1. 核心定义

不依赖角色，通过多维度属性动态计算权限，是云原生、微服务、多租户、复杂权限场景高级方案。
三大属性分类：

1. 用户属性：部门、职级、岗位、用户ID、租户ID
2. 资源属性：数据归属人、资源分类、密级
3. 环境属性：访问时间、IP地址、客户端设备、请求渠道

2. 核心逻辑：策略匹配

编写权限策略规则，运行时提取三方属性代入规则，规则满足则授权。
规则示例：

if (用户.部门 = 销售部) AND (资源.归属租户 = 当前用户租户) AND (访问时间 9:00-18:00)
    允许查看客户数据
else
    拒绝访问

3. 完整执行流程

1. 用户登录，JWT携带用户全部属性（部门、租户、职级等）
2. 请求资源时，后端同时获取：
   • 用户属性（解析JWT）
   • 被访问资源属性（数据库查询数据归属）
   • 环境属性（当前时间、请求IP）
3. 加载预定义ABAC策略规则引擎
4. 将三类属性传入规则引擎做布尔运算
5. 引擎返回允许/拒绝，完成授权

4. 优缺点

优点

1. 极致动态、细粒度数据权限，天然支持行级数据隔离
2. 无需频繁维护角色，规则配置化，后台可视化修改策略无需改代码
3. 天然适配多租户、云平台、风控系统、金融级权限管控

缺点

1. 实现复杂，需要规则引擎（Open Policy Agent OPA）
2. 计算逻辑重，相比RBAC性能损耗更高
3. 中小后台系统过度设计，维护成本高

5. 适用场景

金融系统、多租户SaaS平台、云资源管控、政府分级涉密系统

五、JWT 无状态认证令牌（JSON Web Token）

1. 作用定位

ACL/RBAC/ABAC是授权方案，JWT是跨服务身份认证载体，用来在微服务、前后端分离系统传递用户身份、角色、属性信息。

2. JWT三段结构（Base64编码，非加密）

1. Header 头部：加密算法（HS256/RS256）、令牌类型
2. Payload 载荷（核心）：存放自定义业务数据
   标准字段：exp过期时间、iss签发方、sub用户ID
   自定义字段：roles:[admin,finance]、tenantId、dept（ABAC所需属性全部放这里）
3. Signature 签名：密钥加密头部+载荷，防止篡改

3. JWT 完整登录+鉴权全流程（前后端分离/微服务通用）

步骤1：用户登录获取JWT

1. 前端提交账号密码到登录接口
2. 后端校验账号密码，查询用户角色/属性
3. 组装JWT载荷：userId、roles、租户ID、部门、过期时间
4. 使用密钥生成签名，拼接三段生成完整JWT字符串
5. 返回JWT给前端，前端存储localStorage/cookie

步骤2：前端携带令牌请求所有业务接口

每次HTTP请求Header自动携带：
Authorization: Bearer {JWT字符串}

步骤3：网关/拦截器统一校验JWT（微服务推荐网关校验）

1. 拦截器提取Header中的JWT
2. 使用服务端密钥校验签名：
   • 签名篡改 → 直接返回401令牌非法
   • 校验通过 → 解码Payload，提取用户身份、角色、属性
3. 校验exp过期时间，过期返回401重新登录
4. 将解码后的用户信息存入上下文，向下传递给授权模块

步骤4：授权模块执行ACL/RBAC/ABAC权限校验

根据解码出来的用户信息，执行对应权限逻辑，判断是否放行接口。

步骤5：JWT刷新机制（解决短期过期）

1. AccessToken短期有效（30分钟），用于业务鉴权
2. RefreshToken长期有效（7天），存在数据库绑定用户
3. Access过期后，前端携带RefreshToken调用刷新接口
4. 后端校验RefreshToken合法，下发新AccessToken

4. JWT优缺点

优点

1. 无状态：服务端不存储会话，分布式微服务无需共享Session
2. 自包含：载荷自带角色、属性，不用频繁查数据库获取用户信息
3. 跨域、跨服务友好，适配前后端分离、网关架构

缺点

1. 无法主动失效：令牌未过期前，用户退出登录仍可使用（解决方案：Redis黑名单、短过期时间）
2. 载荷不能存敏感数据：仅Base64编码，可直接解码查看
3. 令牌体积大，每次请求携带增加网络开销

六、ACL vs RBAC vs ABAC 横向对比表

维度	ACL	RBAC	ABAC
核心绑定关系	用户-资源直连	用户-角色-权限	用户/资源/环境多属性规则
维护难度	极高，批量修改麻烦	低，角色批量分配	中等，配置规则引擎
细粒度	接口级，无数据区分	接口级，需扩展实现数据权限	天然支持行级数据权限
动态能力	静态写死，无法动态约束	静态角色，仅固定权限集合	动态规则（时间、IP、租户）
性能	中等	最优，缓存友好	较差，规则计算耗时
适用系统规模	小型单机工具	绝大多数中后台管理系统	SaaS多租户、金融、云平台
配套JWT适配	适配，载荷存userId	完美适配，载荷存roles	完美适配，载荷存全量用户属性

七、企业通用落地组合方案（生产环境推荐）

方案1：中小型后台管理系统（90%项目选用）

RBAC + JWT

• JWT携带userId、角色列表
• 拦截器解析JWT，基于RBAC校验菜单、按钮、接口权限
• 数据范围权限扩展：在RBAC基础上增加用户数据归属字段

方案2：多租户SaaS、金融复杂权限系统

ABAC + JWT + OPA规则引擎

• JWT存放用户部门、租户、职级等全部属性
• 网关解析JWT后，传入OPA引擎执行ABAC策略
• 可视化后台配置权限规则，无需修改代码

方案3：简单内部工具、文件服务器

ACL + JWT
轻量化实现，用户量少场景够用

八、Mermaid 核心流程图（可直接复制到CSDN渲染）

1. RBAC+JWT完整鉴权流程

2. ABAC 授权逻辑流程图

九、总结

1. ACL是最原始权限模型，仅小型工具使用；
2. RBAC是通用标准权限方案，开发成本低、性能好，绝大多数后台首选；
3. ABAC面向复杂动态权限场景，依赖规则引擎，适合多租户、金融系统；
4. JWT是认证载体，和三种授权模型可以任意组合，解决分布式系统身份传递问题；
5. 生产落地优先选择 RBAC + JWT 组合，复杂SaaS平台升级为 ABAC + JWT + OPA。