真实世界系统设计：Authentication、RBAC 和 Multi-Tenant 架构（第 1 部分）

Source: Dev.to

为什么要写这个系列？

大多数教程只会展示：

• “添加 JWT 认证”
• “保护一个路由”
• “创建 admin 和 user 之类的角色”

但真实系统需要回答更难的问题：

• 如何为多个组织（租户）设计认证？
• 各部门或项目的角色如何不同？
• 如何避免权限爆炸？
• 如何在不重写代码的情况下扩展 RBAC？

这些问题我们将一步步解决。

核心构建块

1. 认证（你是谁？）

认证只回答一个问题：

发起此请求的是谁？

常见方式：

• 邮箱/密码
• OAuth（Google、GitHub、SSO）
• 基于令牌的认证（JWT、不透明令牌）
• 基于会话的认证

⚠️ 认证不决定你能做什么，它仅仅证明身份。

2. 授权 & RBAC（你可以做什么？）

授权回答：

这个已认证的用户可以访问或修改什么？

RBAC 是最常用的模型：

Users → Roles → Permissions

在真实系统中：

• 角色随租户而异
• 权限随上下文而异
• 某些操作依赖所有权或层级关系

我们将探讨：

• 简单 RBAC
• 角色‑权限映射
• 上下文感知的权限
• RBAC 失效时的替代方案

3. 多租户架构（你属于哪个组织？）

多租户回答：

哪个组织的数据和规则适用于该用户？

典型场景：

• SaaS 产品
• 企业工具
• 多公司共用的内部平台

关键挑战：

• 数据隔离
• 租户特定的角色和权限
• 在不复制逻辑的情况下实现扩展
• 防止跨租户访问的漏洞

一次遗漏的检查就可能导致安全事件。

我们将在系列中构建的真实案例

在整个系列中，我们会使用一个现实场景：一个被多家公司使用的 SaaS 平台。每家公司拥有部门、用户、角色和权限。

高层结构

Organization (Tenant)
 └── Company
     └── Department
         └── Users
             └── Roles
                 └── Permissions

规则

• 用户只能属于一个租户
• 角色在每个租户内定义
• 权限控制对功能和数据的访问
• 访问取决于角色和上下文两者

这正是许多企业系统的实际工作方式。

团队常犯的早期错误

• ❌ 硬编码角色（例如 if user.role === 'admin'）
• ❌ 认为只有全局 admin 角色
• ❌ 将认证和授权逻辑混在一起
• ❌ 在查询中忽视租户边界
• ❌ 在功能增长后才设计 RBAC

本系列将帮助你规避这些陷阱。

本系列将覆盖的内容

真实系统中的认证

• JWT 与会话的对比
• 令牌生命周期
• 安全登录流程

可扩展的 RBAC 设计

• 角色 vs. 权限的设计
• 数据库模式模式
• 防止角色爆炸

多租户授权

• 租户隔离策略
• 查询层面的安全
• 中间件模式

高级模式

• 基于策略的访问控制
• 基于属性的访问控制（ABAC）
• 功能标记 & 权限门

常见安全陷阱

• 权限提升漏洞
• 不安全的默认设置
• 授权测试策略

目标读者

• 后端工程师
• SaaS 产品开发者
• API 设计者
• 想了解为什么有这些模式，而不仅仅是如何实现的任何人

假设你具备基本的后端开发经验，但这些概念适用于各种技术栈。

下一步

在第 2 部分，我们将从多租户系统中的认证设计开始——如何从第一天起就正确构建身份、令牌和租户上下文。

如果你对真实系统设计模式感兴趣，欢迎持续关注。