认证与授权全攻略：从 Basic、JWT 到 RBAC、ABAC，开发者该怎么选？
![img]()
引言：别搞混！认证和授权是两回事
做开发时，我们常把“认证”和“授权”挂在嘴边，但很多人其实没分清二者的核心区别：
- 认证（Authentication）：解决“你是谁”的问题——比如登录时输密码、扫人脸，本质是确认“用户身份合法”。
- 授权（Authorization）：解决“你能做什么”的问题——比如登录 GitHub 后，你能 push 代码还是只能看仓库，本质是控制“合法用户的操作权限”。
简单说：先“认证”通过，再“授权”判断。少了前者，系统会认错人；少了后者，合法用户可能乱操作（比如普通员工删了公司财务数据）。
这篇文章就把「认证技术」和「授权模型」揉在一起讲透：从基础的账号密码认证，到复杂的第三方授权，再到企业级的权限控制，帮你搞懂不同场景该用什么方案～
第一部分：认证技术——先确认“你是谁”
认证是授权的前提。目前主流的认证技术有 5 种，各有适用场景，别盲目跟风用“高大上”的方案。
1. 最朴素的认证：Basic Auth（基本认证）
工作原理
说穿了就是“账号密码直接传”：客户端把“用户名：密码”用 Base64 编码（注意！不是加密），放在 HTTP 请求头的Authorization里发给服务器，服务器解码后验证身份。 请求头示例：
Authorization: Basic dXNlcjE6cGFzc3dvcmQxMjM=
# 解码后：user1:password123
适合场景
- 仅用于内部极简单的小系统（比如公司内部的测试工具、临时后台）；
- 必须搭配 HTTPS 使用（否则 Base64 编码能被轻易破解，等于裸奔）。
避坑点
绝对不能用在公开系统！比如用户可访问的 App、官网——Base64 解码太容易，随便搜个“Base64 在线解码”就能拿到账号密码。
2. 轻量升级：Bearer Auth（承载认证）
工作原理
比 Basic Auth 灵活一步：用户登录成功后，服务器生成一个随机“令牌（Token）”返回给客户端；之后客户端每次请求，都把 Token 放在Authorization头里，服务器验证 Token 有效性即可。 请求头示例：
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
# 后面的长字符串就是服务器颁发的Token
适合场景
- 中小型前后端分离项目（比如 Vue/React 官网、小体量 App）；
- 不需要复杂权限管理的场景（比如只需要“确认用户已登录”，不用区分“管理员/普通用户”）。
核心优势
Token 可以随时吊销（比如用户登出时，服务器把 Token 加入“黑名单”），而 Basic Auth 的“用户名+密码”一旦泄露，只能让用户改密码——灵活性差很多。
3. 第三方登录的核心：OAuth 2.0（开放授权协议）
先厘清：OAuth 2.0 是“授权”，不是“认证”！
很多人以为 OAuth 2.0 是“登录方式”，其实它本质是委派授权协议：允许用户把“自己在 A 系统的权限”委派给 B 系统，不用把 A 系统的密码告诉 B 系统。
比如你用“微信登录某外卖 App”：
- 你不用把微信密码告诉外卖 App；
- 你只需要授权外卖 App“获取你的微信昵称和头像”；
- 微信给外卖 App 发一个“授权令牌”，App 用这个令牌拿你的信息——这就是 OAuth 2.0 的核心逻辑。
适合场景
- 所有“第三方登录”场景（用 QQ 登录游戏、用 GitHub 登录开源工具、用支付宝登录生活类 App）；
- 跨系统权限共享（比如公司内部“CRM 系统”授权“财务系统”获取客户基本信息，不用重复登录）。
国内常用流程：授权码模式（Authorization Code）
这是最安全的 OAuth 2.0 流程，国内大厂基本都用它：
- 外卖 App 跳转到微信登录页，你输入微信密码完成认证；
- 微信给 App 返回一个“授权码”（临时、一次性有效）；
- App 拿着“授权码”向微信服务器申请“访问令牌（Access Token）”；
- 微信返回“访问令牌”，App 用它获取你的昵称、头像（只能拿你授权的信息）。
4. 前后端分离宠儿：JWT（JSON Web Token）
工作原理
JWT 不是“新认证技术”，而是一种 Token 的标准化格式——把用户信息（比如用户 ID、角色）用 JSON 封装，加上“头部（算法）”和“签名（防篡改）”，生成“头部。载荷。签名”三段式字符串。
示例 JWT：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNjQyMDgwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
- 头部：说明签名算法（比如
HS256）；
- 载荷：存放非敏感用户信息（比如
userId:1、role:admin）；
- 签名：用服务器“密钥”生成，服务器收到 JWT 后会重新计算签名，确认是否被篡改。
适合场景
- 前后端分离项目（前端存 JWT，后端不用存 Session，直接解析 Token 拿用户信息）；
- 分布式系统（多个服务共享用户信息，不用每个服务都查数据库）。
避坑点
- 载荷是 Base64 编码明文，绝对不能存密码、手机号等敏感数据；
- 密钥要保管好！一旦密钥泄露，攻击者能伪造任意 JWT；
- JWT 本身不能吊销（除非加“黑名单”机制），所以过期时间别设太长（比如 1-2 小时）。
5. 企业级统一登录：SSO（单点登录）
工作原理
解决“多系统只登一次”的痛点：企业搭建一个“统一认证中心”，所有内部系统都信任这个中心。你在任何一个系统登录，其实都是在“认证中心”登录；之后访问其他系统时，系统会向“认证中心”确认你的登录状态，不用再输密码。
比如你登录阿里的“淘宝”后，再打开“支付宝”“天猫”，不用重新登录——背后就是 SSO 在工作。
适合场景
- 企业内部多系统（OA、CRM、财务、人事系统）；
- 同一公司旗下的多个产品（比如字节的“抖音”登录后，“今日头条”自动登录）。
和 OAuth 2.0 的区别
- OAuth 2.0：侧重“跨公司/跨平台的授权”（比如外卖 App 用微信授权）；
- SSO：侧重“同一公司内部的统一认证”（比如阿里系产品统一登录）。
第二部分：授权模型——再判断“你能做什么”
认证通过后，系统需要明确“用户能操作哪些资源”。目前主流的授权模型有 3 种，实际系统常混合使用。
1. 最常用：RBAC（基于角色的访问控制）
核心逻辑：“用户→角色→权限”三层映射
先定义“角色”，给角色分配“权限”，再把角色分配给用户——不用给每个用户单独设置权限，管理起来很简单。
示例：
- 角色 1：Admin（管理员）→ 权限：删用户、改配置、看所有数据；
- 角色 2：Editor（编辑）→ 权限：改内容、发文章、不能删用户；
- 角色 3：Viewer（查看者）→ 权限：只能看内容，不能改。
适合场景
- 绝大多数系统（Stripe 控制台、CMS 工具、企业后台）；
- 权限层级清晰、变化不频繁的场景（比如公司只有“管理员/编辑/普通用户”三类角色）。
优势：简单、易扩展
比如公司新增 10 个“编辑”，不用给每个人分配“发文章”权限——直接把“Editor”角色分配给他们就行，管理成本极低。
2. 最灵活：ABAC（基于属性的访问控制）
核心逻辑：“属性+条件”动态判断
不依赖固定角色，而是根据“用户属性”“资源属性”“环境属性”动态判断权限。条件可以写得很精细，比如：
允许操作 = （用户部门 == "HR"） && （操作时间 < 18:00） && （资源类型 == "员工档案"）
适合场景
- 权限规则复杂、需要动态调整的场景；
- 行业特定需求（比如银行系统：“只有本支行员工，在工作时间内，才能查看本支行客户的账户信息”）。
优势与缺点
- 优势：灵活性极高，能满足复杂业务规则；
- 缺点：复杂度高，需要专门的“政策引擎”管理规则（比如 Auth0、Keycloak），小系统用起来没必要。
3. 最精细：ACL（基于访问控制列表）
核心逻辑：“资源→用户/组”直接映射
给每个资源单独设置“访问控制列表（ACL）”，明确“哪些用户/组能操作这个资源”。
示例：
- 资源：你在 Google Drive 的“2024 财务报表。xlsx”;
- ACL 设置：
- 张三：可编辑；
- 李四：可评论；
- 其他同事：只能查看。
适合场景
- 资源粒度极细的场景（云存储文件、个人项目协作）；
- 用户需要自主管理资源权限的场景（比如你分享自己的文件给同事）。
优势与缺点
- 优势：权限控制到单个资源，粒度最细；
- 缺点：难扩展——如果有 100 万个文件，每个文件都要维护 ACL，管理成本会爆炸（除非用工具抽象，比如阿里云 OSS 的访问控制）。
第三部分：实战结合——认证与授权怎么搭配用？
实际系统里，认证和授权不是孤立的，而是配合工作的。举几个常见搭配案例：
案例 1：中小型后台系统（RBAC + JWT）
- 认证：用户用账号密码登录，服务器生成 JWT（载荷包含
userId和role）；
- 授权：前端每次请求带 JWT，后端解析出
role，用 RBAC 判断权限（比如role=admin才能访问“删用户”接口）；
- 优势：不用存 Session，前后端分离友好，权限管理简单。
案例 2：第三方登录 App（OAuth 2.0 + RBAC）
- 认证：用户用“微信登录”App，App 通过 OAuth 2.0 拿到微信的“访问令牌”，获取用户昵称/头像；
- 授权：App 给用户分配“普通用户”角色（RBAC），用户只能操作“下单”“查订单”等权限；
- 优势：用户不用注册新账号，App 不用存用户密码，安全又方便。
案例 3：企业内部系统（SSO + ABAC）
- 认证：用户登录“企业认证中心”（SSO），之后访问 OA、CRM 系统不用再登录；
- 授权：访问“员工档案”时，系统用 ABAC 判断（比如“HR 部门员工+工作时间”才能查看）；
- 优势：统一认证提升体验，复杂条件满足企业合规需求（比如 GDPR、等保）。
第四部分：选型指南——不同场景该怎么选？
用一张表总结所有技术/模型的核心差异，帮你快速选型：
| 类型 |
技术/模型 |
核心优势 |
适合场景 |
避坑点 |
| 认证技术 |
Basic Auth |
实现简单 |
内部极小系统（搭配 HTTPS） |
别用在公开系统，Base64 易解码 |
|
Bearer Auth |
Token 可吊销，比 Basic 灵活 |
中小型前后端分离项目 |
Token 要防 XSS（前端别存 localStorage） |
|
OAuth 2.0 |
第三方授权，不用传密码 |
第三方登录、跨系统权限共享 |
公开 App 用“授权码模式”，别用“密码模式” |
|
JWT |
无状态，适合分布式 |
前后端分离、多服务共享用户信息 |
载荷不存敏感数据，密钥要保管好 |
|
SSO |
多系统统一登录 |
企业内部多系统、同公司多产品 |
认证中心要高可用，否则所有系统瘫痪 |
| 授权模型 |
RBAC |
简单易管理，易扩展 |
绝大多数系统（后台、CMS） |
别过度设计角色（比如角色超过 10 个） |
|
ABAC |
灵活，支持复杂规则 |
银行、医疗等合规要求高的场景 |
小系统别用，复杂度高 |
|
ACL |
权限粒度细，用户可自主 |
云存储、个人文件协作 |
资源多了难扩展，需工具抽象 |
结尾：学习资源推荐
如果想深入实战，推荐两个方向：
- 工具实践：用 Keycloak（开源认证授权工具）搭建 SSO+RBAC 系统，国内可访问文档：Keycloak 中文指南；
- 视频学习：原作者的 YouTube 视频（若无法访问，可搜 B 站“OAuth2 JWT 实战”，有很多国内开发者的讲解）。
认证授权是系统安全的基石，别一开始就用“最复杂的方案”——先明确业务需求，再选最适合的技术，才是高效的开发思路～
