1. 课程导入与全局认知

在开始任何具体技术之前，先把三个最容易混淆的概念摆清楚：认证（Authentication）回答“你是谁”，授权（Authorization）回答“你能做什么”，权限系统（Permission System）则是把“谁能对什么资源做什么操作”这套规则持久化、可查询、可审计地管理起来的基础设施。三者不是同义词，也不是简单的先后步骤，而是三个不同层次、不同失败模式的关注点。

很多生产事故的根因，恰恰是把它们混为一谈。例如，用户登录成功（认证通过）并不代表他能访问订单详情接口——那需要授权判断；而授权判断通过，也不代表这次访问会被记录、能被追溯、能在权限变更后立即失效——那需要权限系统的策略存储与缓存失效机制。本节的目标，是建立一张全局地图，让你在后续 29 章中始终知道自己在解决哪一层的问题。

三者的边界与关系

用一个具体场景来区分。假设有一个电商后台系统，运营人员小李要查看“2024 年 6 月华东区退款订单”。这个请求经过的链路是：

• 认证层：小李通过账号密码 + 短信验证码登录，系统签发一个 JWT，其中包含 sub=user_1024、exp=1720000000。认证层只关心凭证是否有效、是否过期、是否被吊销。
• 授权层：网关或业务服务解析 JWT 后，判断 user_1024 是否拥有 order:refund:read 这个权限，以及该权限是否限定在“华东区”这个数据范围内。授权层关心的是“这个主体对这个资源做这个操作，是否被允许”。
• 权限系统：上述权限从哪来？它由权限系统管理——角色 regional_operator 被授予 order:refund:read，小李被分配了该角色，且角色绑定了数据范围 region=east。权限系统负责存储、查询、变更、审计这些关系。

三者的关系可以概括为：认证是入口，授权是闸门，权限系统是闸门背后的规则库和调度中心。认证失败通常表现为 401，授权失败通常表现为 403，而权限系统故障可能表现为“所有人都能访问”或“所有人都不能访问”这类更危险的全局性问题。

生产环境中的典型挑战

把这三层放到真实生产环境里，挑战会立刻变得具体。以下四类问题在后续章节中会反复出现，这里先建立认知锚点。

第一类：边界模糊导致的越权。最常见的是“认证通过即放行”。例如某内部系统在网关层只校验 JWT 签名，不校验权限，业务服务默认信任网关传来的 X-User-Id。一旦网关配置错误或存在绕过路径，攻击者可以伪造用户 ID 直接访问任意接口。治理目标不是“加一个中间件”，而是建立零信任的授权判定点：每个敏感操作都必须经过独立的权限判定，不依赖上游的“已认证”结论。

第二类：权限数据不一致。权限系统通常有数据库和缓存两层。运营在后台把用户从角色 A 移到角色 B，数据库已更新，但 Redis 中的权限缓存 TTL 还有 10 分钟。这 10 分钟内，用户仍然拥有角色 A 的权限。如果角色 A 包含“删除订单”而角色 B 不包含，这就是一个真实的安全窗口。治理目标是可观测的缓存失效策略：变更时主动失效、设置合理 TTL、并提供“权限生效延迟”监控指标。

第三类：权限爆炸与治理失控。随着业务增长，角色数量从 10 个膨胀到 300 个，权限点从 50 个膨胀到 2000 个。没有人知道 role_ops_legacy_2022 到底能做什么，也不敢删。治理目标是权限可解释性：每个角色必须有负责人、有描述、有最后使用时间，并支持“权限影响面分析”——修改一个角色前，能查出影响多少用户、多少接口。

第四类：故障时无法快速定位。用户反馈“我明明有权限，为什么 403？”排查时发现：JWT 里的角色声明是旧的、网关缓存没刷新、权限系统 API 超时降级为拒绝。三个原因叠加，没有链路追踪就无法定位。治理目标是端到端的授权决策日志：每次判定记录主体、资源、操作、决策结果、命中的策略、耗时，并关联 traceId。

课程学习路径与实战项目

本课程共 30 章，按“认知 → 建模 → 实现 → 治理”四段推进。前 6 章建立概念与模型：认证协议选型、RBAC/ABAC/ReBAC 的适用边界、权限数据模型设计。第 7 到 15 章进入实现：JWT 与 Session 的取舍、网关与微服务的授权链路、数据权限的行级/列级过滤、权限缓存与失效。第 16 到 24 章聚焦治理：权限审计、最小权限落地、越权检测、灰度与回滚。最后 6 章是故障治理专题：典型故障树、排查手册、压测与混沌演练、合规与等保要求。

贯穿全程的实战项目是一个多租户 SaaS 工单系统的权限模块。它包含以下真实约束：

• 三种角色：tenant_admin（租户管理员）、agent（客服）、viewer（只读）；
• 数据范围：租户隔离 + 客服只能看自己负责的工单；
• 权限点示例：ticket:read、ticket:assign、ticket:close、tenant:user:manage；
• 技术栈：Spring Boot + Spring Security + Redis + MySQL，网关层做认证，服务层做授权。

你会在后续章节中逐步为这个项目实现：JWT 签发与校验、基于 @PreAuthorize 的接口级授权、MyBatis 拦截器实现行级数据过滤、Redis 缓存权限并处理失效、以及一套可查询的授权决策日志。每完成一个模块，都会给出可运行的配置片段、测试用例和预期结果，而不是停留在概念层面。

最后强调一个贯穿全课程的原则：认证可以集中，授权必须分散到每个决策点，而权限系统要保证分散的决策点看到一致的规则。这三句话分别对应三层，也对应三种不同的故障模式和治理手段。接下来的 29 章，就是把这套认知变成可落地、可验证、可运维的工程实践。