4. 权限隔离基础：认证与授权的区别
做过多租户系统的朋友都清楚，权限隔离是这条路上的第一道坎。而很多新手甚至老鸟，最容易搞混的就是认证和授权。说白了，这两件事虽然天天一起出现，但本质完全不同。我刚开始做多租户系统时，就在这个问题上栽过跟头。
4.1 概念区别：你是谁 vs 你能做什么
认证（Authentication）解决的是「你是谁」的问题。用户拿用户名密码、OTP或者SSO令牌来，系统验证这个身份是否合法。授权（Authorization）解决的是「你能做什么」的问题。身份确认了，但你在某个租户下能看什么、改什么，由授权决定。
举个例子。你走进公司大楼，门禁刷脸——这是认证，证明你是员工。进了大门，你的工卡只能刷开自己部门的门，财务部你进不去——这是授权。我见过不少系统，认证做得很严，但授权就是一把大锁，所有人进来都一样权限，这在多租户场景下就是灾难。
| 维度 | 认证 | 授权 |
|---|---|---|
| 核心问题 | 你是谁？ | 你能做什么？ |
| 输入 | 凭据（密码、证书、） | 身份信息 + 请求上下文 |
| 输出 | 身份声明（Principal / Identity） | 访问决策（Allow / Deny） |
| 存储 | 凭据库、LDAP、IdP | 策略引擎、RBAC/ABAC 模型 |
| 变更频率 | 低（密码重置、SSO 配置变更） | 高（角色、权限策略频繁调整） |
避坑指南
我曾经帮一个团队排查故障，发现他们的 API 把认证和授权混在一个过滤器里处理。结果租户 A 的管理员用了一个跨租户的 ，居然能看到租户 B 的数据。原因就是认证通过后，授权逻辑忘了校验 tenant_id。所以，这两块必须解耦。
4.2 为什么必须分开实现？
你想想看，如果认证和授权搅在一起，会出什么问题？
- 扩展性差：想换个认证方式（比如从密码换到 OAuth），得改授权代码，风险极高。
- 审计混乱：日志里分不清是认证失败还是授权拒绝，排障时全靠猜。
- 租户隔离不可控：策略逻辑和身份验证耦合，租户间的权限交叉难以追踪。
我个人习惯把认证层和授权层做成独立的服务或者中间件。认证层只负责颁发身份令牌，授权层拿着令牌去查策略。这样做的好处很明显：认证挂了不影响授权策略的调整，反过来也一样。
架构设计要点
在网关层完成认证，生成包含租户 ID、用户 ID、角色列表的 JWT。业务服务只认这个 JWT，然后通过授权中间件校验具体操作权限。网关不碰业务逻辑，业务服务不碰密码——各司其职。
4.3 演进路径：从简单认证到精细授权
很多多租户系统不是一开始就设计好的，而是逐步演进的。我接触过的项目，大体走过这三个阶段：
- 初级阶段：共享认证 + 租户标识
用户表里加个 tenant_id 字段。登录时查数据库，验证密码同时返回租户信息。授权呢？就是看看这个 API 路径是不是属于当前租户。简单粗暴，但租户多了根本扛不住。
- 中级阶段：独立认证中心 + 粗粒度 RBAC
把认证抽出来做成公共服务，用 OAuth2 / OIDC 标准协议。授权用基于角色的模型，每个租户可以自定义角色。但角色爆炸问题开始出现。
- 高级阶段：零信任架构 + 细粒度 ABAC
认证、授权、审计彻底分离。授权升级为基于属性的模型，可以按用户属性、资源标签、环境上下文做判断。每次请求都做一次完整的鉴权决策，不信任任何网络边界。
我的建议
不要一开始就上 ABAC，那个策略配置的复杂度很高。先做到认证和授权解耦，把 RBAC 跑通，再逐步引入属性条件。我在一个日活千万的 SaaS 项目上就是这么过来的，每一步都踩过坑，但也积累了实战经验。
4.4 关键维度对比：认证 vs 授权
为了让你更直观地理解，我做了一个对比表。这张表我每次培训都会拿出来讲，因为很多人就是在这几个维度上犯浑。
| 对比维度 | 认证 | 授权 |
|---|---|---|
| 执行时机 | 请求进入系统的第一道门 | 认证通过后，处理具体资源前 |
| 判断依据 | 凭据的真实性 | 策略规则 + 上下文 |
| 错误响应 | 401 Unauthorized（名字容易误导） | 403 Forbidden |
| 常见实现 | JWT、Session、OAuth2、SAML | RBAC、ABAC、ACL、PDP |
| 多租户关注点 | 租户识别、身份联邦、SSO | 租户级角色、资源隔离、跨租户策略 |
这里必须提一下 HTTP 状态码的问题。401 和 403 的命名，我猜设计者也觉得别扭，但历史原因改不了。所以你在写文档或做错误处理时，别被名字带偏。认证失败永远是 401，授权失败才是 403。我见过很多团队返回 401 表示授权不足，结果前端把用户踢去重新登录，用户体验极差。
4.5 三种不同场景的实践选择
不同的多租户系统，对认证和授权的侧重点不一样。我整理了几种常见场景：
- 内部管理平台：用户量小，但权限要求严格。认证用 LDAP 或者企业 SSO，授权用 RBAC 精细到按钮级别。租户隔离靠组织树。
- SaaS 开放 API：用户量大，租户多。认证用 + JWT 双因素，授权用 ABAC 按资源标签控制。重点防范跨租户越权。
- 大规模 B2B 平台：既有平台管理员又有客户管理员。认证做身份联邦，允许客户自建 IdP。授权分两层：平台层 RBAC + 租户内 ABAC。
经验分享
我记得有一次，客户要求租户 A 的管理员能临时查看租户 B 的报表用于对账。这个需求乍一看是「授权越界」，但其实是业务合理。最后我们通过「临时委托授权」来处理：认证仍然是各自独立的，但授权策略里增加了一个「跨租户视图」的临时角色，并附带了时间限制和审计日志。核心就是认证不动，授权弹性处理。
4.6 先分清楚，再谈隔离
总结一下。认证和授权是两回事，但很多人把它们当一回事。先分清楚，再谈后面的租户隔离、权限模型、审计日志。如果这一步没想明白，后面的代码写得再漂亮，隔离也有漏洞。
你想想看，多租户系统的核心是什么？是信任边界。认证确立了用户的身份边界，授权确立了用户的操作边界。两条边界必须清晰、独立、可审计。嗯，这就是我们做权限隔离的第一课。