认证与授权全攻略：从 Basic、JWT 到 RBAC、ABAC，开发者该怎么选？

引言：别搞混！认证和授权是两回事

做开发时，我们常把“认证”和“授权”挂在嘴边，但很多人其实没分清二者的核心区别：

• 认证（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 流程，国内大厂基本都用它：

1. 外卖 App 跳转到微信登录页，你输入微信密码完成认证；
2. 微信给 App 返回一个“授权码”（临时、一次性有效）；
3. App 拿着“授权码”向微信服务器申请“访问令牌（Access Token）”；
4. 微信返回“访问令牌”，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）

1. 认证：用户用账号密码登录，服务器生成 JWT（载荷包含userId和role）；
2. 授权：前端每次请求带 JWT，后端解析出role，用 RBAC 判断权限（比如role=admin才能访问“删用户”接口）；
3. 优势：不用存 Session，前后端分离友好，权限管理简单。

案例 2：第三方登录 App（OAuth 2.0 + RBAC）

1. 认证：用户用“微信登录”App，App 通过 OAuth 2.0 拿到微信的“访问令牌”，获取用户昵称/头像；
2. 授权：App 给用户分配“普通用户”角色（RBAC），用户只能操作“下单”“查订单”等权限；
3. 优势：用户不用注册新账号，App 不用存用户密码，安全又方便。

案例 3：企业内部系统（SSO + ABAC）

1. 认证：用户登录“企业认证中心”（SSO），之后访问 OA、CRM 系统不用再登录；
2. 授权：访问“员工档案”时，系统用 ABAC 判断（比如“HR 部门员工+工作时间”才能查看）；
3. 优势：统一认证提升体验，复杂条件满足企业合规需求（比如 GDPR、等保）。

第四部分：选型指南——不同场景该怎么选？

用一张表总结所有技术/模型的核心差异，帮你快速选型：

类型	技术/模型	核心优势	适合场景	避坑点
认证技术	Basic Auth	实现简单	内部极小系统（搭配 HTTPS）	别用在公开系统，Base64 易解码
	Bearer Auth	Token 可吊销，比 Basic 灵活	中小型前后端分离项目	Token 要防 XSS（前端别存 localStorage）
	OAuth 2.0	第三方授权，不用传密码	第三方登录、跨系统权限共享	公开 App 用“授权码模式”，别用“密码模式”
	JWT	无状态，适合分布式	前后端分离、多服务共享用户信息	载荷不存敏感数据，密钥要保管好
	SSO	多系统统一登录	企业内部多系统、同公司多产品	认证中心要高可用，否则所有系统瘫痪
授权模型	RBAC	简单易管理，易扩展	绝大多数系统（后台、CMS）	别过度设计角色（比如角色超过 10 个）
	ABAC	灵活，支持复杂规则	银行、医疗等合规要求高的场景	小系统别用，复杂度高
	ACL	权限粒度细，用户可自主	云存储、个人文件协作	资源多了难扩展，需工具抽象

结尾：学习资源推荐

如果想深入实战，推荐两个方向：

1. 工具实践：用 Keycloak（开源认证授权工具）搭建 SSO+RBAC 系统，国内可访问文档：Keycloak 中文指南；
2. 视频学习：原作者的 YouTube 视频（若无法访问，可搜 B 站“OAuth2 JWT 实战”，有很多国内开发者的讲解）。

认证授权是系统安全的基石，别一开始就用“最复杂的方案”——先明确业务需求，再选最适合的技术，才是高效的开发思路～