<h1>认证与授权全攻略：从 Basic、JWT 到 RBAC、ABAC，开发者该怎么选？</h1> 引言：别搞混！认证和授权是两回事
做开发时，我们常把“认证”和“授权”挂在嘴边，但很多人其实没分清二者的核心区别：
- 认证（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 设置：
- 张三：可编辑；
- 李四：可评论；
- 其他同事：只能查看。
