---
URL: "/zh-CN/blog/2025-09/authencate-authorize.html"
LLMS_URL: "/zh-CN/blog/2025-09/authencate-authorize.md"
lastUpdated: true
commentabled: true
recommended: true
title: "认证与授权全攻略"
description: "从 Basic、JWT 到 RBAC、ABAC，开发者该怎么选？"
date:

pageClass: "blog-page-class"
cover: "/covers/platform.svg"
---

---
lastUpdated: true
commentabled: true
recommended: true
title: 认证与授权全攻略
description: 从 Basic、JWT 到 RBAC、ABAC，开发者该怎么选？
date: 2025-09-25 09:00:00 
pageClass: blog-page-class
cover: /covers/platform.svg
---

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

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

- **认证（Authentication）**：解决“你是谁”的问题——比如登录时输密码、扫人脸，本质是确认“用户身份合法”。
- **授权（Authorization）**：解决“你能做什么”的问题——比如登录 GitHub 后，你能 push 代码还是只能看仓库，本质是控制“合法用户的操作权限”。

简单说：先“认证”通过，再“授权”判断。少了前者，系统会认错人；少了后者，合法用户可能乱操作（比如普通员工删了公司财务数据）。

这篇文章就把「认证技术」和「授权模型」揉在一起讲透：从基础的账号密码认证，到复杂的第三方授权，再到企业级的权限控制，帮你搞懂不同场景该用什么方案～

## 第一部分：认证技术——先确认“你是谁” ##

认证是授权的前提。目前主流的认证技术有 5 种，各有适用场景，别盲目跟风用“高大上”的方案。

### 最朴素的认证：Basic Auth（基本认证） ###

**工作原理**

说穿了就是“账号密码直接传”：客户端把“用户名：密码”用 Base64 编码（注意！不是加密），放在 HTTP 请求头的 `Authorization` 里发给服务器，服务器解码后验证身份。 请求头示例：

```txt
Authorization: Basic dXNlcjE6cGFzc3dvcmQxMjM= 
# 解码后：user1:password123
```

**适合场景**

- 仅用于*内部极简单的小系统*（比如公司内部的测试工具、临时后台）；
- 必须搭配 HTTPS 使用（否则 Base64 编码能被轻易破解，等于裸奔）。

**避坑点**

绝对不能用在公开系统！比如用户可访问的 App、官网——Base64 解码太容易，随便搜个“Base64 在线解码”就能拿到账号密码。

### 轻量升级：Bearer Auth（承载认证） ###

**工作原理**

比 Basic Auth 灵活一步：用户登录成功后，服务器生成一个随机“令牌（Token）”返回给客户端；之后客户端每次请求，都把 Token 放在 `Authorization` 头里，服务器验证 Token 有效性即可。 请求头示例：

```txt
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... 
# 后面的长字符串就是服务器颁发的Token
```

**适合场景**

- 中小型前后端分离项目（比如 Vue/React 官网、小体量 App）；
- 不需要复杂权限管理的场景（比如只需要“确认用户已登录”，不用区分“管理员/普通用户”）。

**核心优势**

Token 可以随时吊销（比如用户登出时，服务器把 Token 加入“黑名单”），而 Basic Auth 的“用户名+密码”一旦泄露，只能让用户改密码——灵活性差很多。

### 第三方登录的核心：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 用它获取你的昵称、头像（只能拿你授权的信息）。

### 前后端分离宠儿：JWT（JSON Web Token） ###

**工作原理**

JWT 不是“新认证技术”，而是一种 *Token 的标准化格式*——把用户信息（比如用户 ID、角色）用 JSON 封装，加上“头部（算法）”和“签名（防篡改）”，生成“头部。载荷。签名”三段式字符串。

示例 JWT：

```txt
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNjQyMDgwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
```

- 头部：说明签名算法（比如 `HS256`）；
- 载荷：存放非敏感用户信息（比如 `userId:1`、`role:admin`）；
- 签名：用服务器“密钥”生成，服务器收到 JWT 后会重新计算签名，确认是否被篡改。

**适合场景**

- 前后端分离项目（前端存 JWT，后端不用存 Session，直接解析 Token 拿用户信息）；
- 分布式系统（多个服务共享用户信息，不用每个服务都查数据库）。

**避坑点**

- 载荷是 *Base64 编码明文*，绝对不能存密码、手机号等敏感数据；
- 密钥要保管好！一旦密钥泄露，攻击者能伪造任意 JWT；
- JWT 本身不能吊销（除非加“黑名单”机制），所以过期时间别设太长（比如 1-2 小时）。

### 企业级统一登录：SSO（单点登录） ###

**工作原理**

解决“多系统只登一次”的痛点：企业搭建一个“统一认证中心”，所有内部系统都信任这个中心。你在任何一个系统登录，其实都是在“认证中心”登录；之后访问其他系统时，系统会向“认证中心”确认你的登录状态，不用再输密码。

比如你登录阿里的“淘宝”后，再打开“支付宝”“天猫”，不用重新登录——背后就是 SSO 在工作。

**适合场景**

- 企业内部多系统（OA、CRM、财务、人事系统）；
- 同一公司旗下的多个产品（比如字节的“抖音”登录后，“今日头条”自动登录）。

**和 OAuth 2.0 的区别**

- OAuth 2.0：侧重“跨公司/跨平台的授权”（比如外卖 App 用微信授权）；
- SSO：侧重“同一公司内部的统一认证”（比如阿里系产品统一登录）。

## 第二部分：授权模型——再判断“你能做什么” ##

认证通过后，系统需要明确“用户能操作哪些资源”。目前主流的授权模型有 3 种，实际系统常混合使用。

### 最常用：RBAC（基于角色的访问控制） ###

**核心逻辑：“用户→角色→权限”三层映射**

先定义“角色”，给角色分配“权限”，再把角色分配给用户——不用给每个用户单独设置权限，管理起来很简单。

示例：

- 角色 1：Admin（管理员）→ 权限：删用户、改配置、看所有数据；
- 角色 2：Editor（编辑）→ 权限：改内容、发文章、不能删用户；
- 角色 3：Viewer（查看者）→ 权限：只能看内容，不能改。

**适合场景**

- 绝大多数系统（Stripe 控制台、CMS 工具、企业后台）；
- 权限层级清晰、变化不频繁的场景（比如公司只有“管理员/编辑/普通用户”三类角色）。

**优势：简单、易扩展**

比如公司新增 10 个“编辑”，不用给每个人分配“发文章”权限——直接把“Editor”角色分配给他们就行，管理成本极低。

### 最灵活：ABAC（基于属性的访问控制） ###

**核心逻辑：“属性+条件”动态判断**

不依赖固定角色，而是根据“用户属性”“资源属性”“环境属性”动态判断权限。条件可以写得很精细，比如：

```txt
允许操作 = （用户部门 == "HR"） && （操作时间 < 18:00） && （资源类型 == "员工档案"）
```

**适合场景**

- 权限规则复杂、需要动态调整的场景；
- 行业特定需求（比如银行系统：“只有本支行员工，在工作时间内，才能查看本支行客户的账户信息”）。

**优势与缺点**

- 优势：灵活性极高，能满足复杂业务规则；
- 缺点：复杂度高，需要专门的“政策引擎”管理规则（比如 Auth0、Keycloak），小系统用起来没必要。

### 最精细：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 | 权限粒度细，用户可自主 | 云存储、个人文件协作 | 资源多了难扩展，需工具抽象 |