2、认证与授权基础：什么是认证（Authentication）？什么是授权（Authorization）？核心概念辨析
好，咱们正式开始聊微服务安全。很多新手容易把认证和授权搞混，甚至有些做了两三年的开发，面试时也说不清楚。我当年刚带团队时，就吃过这个亏——一个接口权限没控制好，差点让内部数据泄露出去。今天咱们就把这两个概念彻底掰扯清楚。
2.1 什么是认证（Authentication）？
认证，说白了就是「你是谁？」。系统要确认你的身份，你得拿出证据来。
最常见的认证方式就是用户名+密码。你输入账号密码，系统去数据库里比对，匹配上了就放你进来。但微服务架构下，认证可没那么简单。
我习惯把认证分为三个层次：
- 身份声明：你说你是谁（比如输入用户名）
- 身份证明：你拿出证据（密码、指纹、短信验证码）
- 身份验证：系统核实证据是否有效
嗯，这里要注意：认证只解决「你是不是你声称的那个人」，不解决「你能干什么」。
核心要点：认证是验证身份的过程。常见的认证因子有三类：
- 知识因子：你知道什么（密码、PIN码）
- 拥有因子：你有什么（手机、硬件令牌）
- 固有因子：你是什么（指纹、人脸、虹膜）
我在项目中遇到过最典型的认证问题：某次做支付系统，用户登录后session被劫持，攻击者直接拿着session ID冒充用户操作。后来我们强制加了双因子认证，才把风险降下来。
2.2 什么是授权（Authorization）？
授权解决的是「你能干什么？」。认证通过后，系统得决定你有哪些权限。
举个例子：你登录了公司OA系统（认证通过），但你是普通员工，不能查看财务数据（授权拒绝）。这就是认证和授权的区别。
授权的核心模型其实就三种：
| 模型 | 说明 | 适用场景 |
|---|---|---|
| DAC（自主访问控制） | 资源所有者自己决定谁可以访问 | 文件共享、个人网盘 |
| MAC（强制访问控制） | 系统根据安全标签强制控制 | 军事系统、政府机密 |
| RBAC（基于角色的访问控制） | 通过角色关联权限 | 企业应用、微服务架构（最常用） |
我个人最推荐RBAC。为什么？因为微服务里服务数量多、用户量大，直接给每个用户分配权限会疯掉。通过角色来管理，清晰又灵活。
实战小技巧：设计授权系统时，我建议把「角色」和「权限」分开存储。角色是权限的集合，用户只关联角色。这样哪天业务方说「给运营加个导出功能」，你只需要改角色的权限配置，不用一个个改用户。
2.3 认证 vs 授权：核心辨析
这两个概念太容易混淆了。我见过不少系统，认证通过了就以为授权也过了，结果权限漏洞一大堆。
咱们用一张表说清楚：
| 维度 | 认证（Authentication） | 授权（Authorization） |
|---|---|---|
| 核心问题 | 你是谁？ | 你能做什么？ |
| 执行顺序 | 先认证，后授权 | 认证通过后才进行 |
| 传递信息 | 用户身份标识（user_id, token） | 权限范围（scope, role） |
| 失败结果 | 401 Unauthorized（其实应该叫未认证） | 403 Forbidden |
| 常见实现 | JWT、Session、OAuth2的授权码流程 | RBAC、ABAC、ACL |
你想想看，HTTP状态码里401和403的区别，其实就是认证和授权的区别。401是说「你没登录，请先认证」，403是说「你登录了，但没权限」。很多开发者把这两个状态码混用，这是不对的。
避坑指南：我曾经接手过一个老项目，所有接口只要认证通过就放行，根本没做授权校验。结果一个普通用户能调用管理员接口删除数据。嗯，那次事故让我养成了一个习惯——每个微服务接口，认证和授权必须分开校验，缺一不可。
2.4 微服务中的认证与授权挑战
单体应用时代，认证授权都在一个进程里，session共享就行。但微服务架构下，服务拆分了，问题就来了：
- 认证状态怎么共享？用户登录后，A服务认了，B服务不认，怎么办？
- 权限怎么传递？服务间调用时，怎么知道调用方是谁、有什么权限？
- 性能怎么保证？每个请求都去认证中心查一遍，延迟受不了。
我常用的解决方案是：用JWT（JSON Web Token）做认证令牌。用户登录后，认证中心签发一个JWT，里面包含用户身份和权限信息。后续请求带着JWT，每个服务自己验证签名就行，不用每次都查数据库。
但JWT也不是银弹。我记得有一次，JWT过期时间设得太长，用户离职了还能访问系统。后来我们强制把JWT有效期设为15分钟，配合refresh token机制，既保证了安全，又提升了体验。
微服务认证授权的黄金法则：
- 认证集中化（统一认证中心）
- 授权分散化（每个服务自己做权限校验）
- 令牌标准化（统一使用JWT或OAuth2）
- 通信加密化（服务间调用必须用TLS）
2.5 一个简单的认证授权流程示例
光说不练假把式。咱们看一个典型的微服务认证授权流程：
// 伪代码：用户登录认证
POST /api/auth/login
{
"username": "alice",
"password": "xxxx"
}
// 认证中心返回JWT
{
"access_token": "eyJhbGciOiJIUzI1NiIs...",
"token_type": "Bearer",
"expires_in": 900
}
// 用户携带JWT访问订单服务
GET /api/orders
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
// 订单服务验证JWT，并检查权限
// 1. 验证签名（确保令牌未被篡改）
// 2. 检查过期时间
// 3. 从JWT中提取角色/权限
// 4. 判断是否有"order:read"权限
// 5. 有权限则返回数据，否则返回403
这个流程看起来简单，但实际落地时坑很多。比如JWT的签名密钥怎么管理？多个服务怎么共享公钥？权限变更后JWT里的信息怎么同步？这些问题咱们后面的章节会一一拆解。
我的个人习惯：在设计认证授权系统时，我会先画一张「信任边界图」。把系统分成几个信任域：用户端、API网关、内部服务、数据库。每个边界上明确认证和授权的检查点。这样架构清晰，不容易漏掉安全控制。
2.6 小结
认证和授权，一个是「验明正身」，一个是「划定权限」。两者缺一不可，顺序也不能乱。微服务架构下，这两个概念更加重要——服务多了，攻击面也大了，任何一个环节出问题都可能引发连锁反应。
下一章咱们会深入聊JWT的具体实现，包括签名算法、过期策略、刷新机制。到时候我会拿一个真实项目的代码来讲解，保证你能直接用到工作中。
记住一句话：认证是门禁卡，授权是房间钥匙。门禁卡能让你进大楼，但每个房间的钥匙得单独配。微服务安全，就从这两个概念开始。