多租户身份验证和授权设置的终极指南
创建一个多租户应用程序可能很复杂。本文收集了我们过去所有关于多租户和组织策略的文章。我们希望这能帮助你节省时间，轻松入门。
Product & Design
构建多租户应用程序可能充满挑战，需要考虑许多方面。本文汇编了我们以前所有关于理解多租户和组织实践的博文。为了快速启动并节省时间，请查看这篇文章，其中包含你所需的一切内容！
总体指南概述如下步骤：
- 了解多租户架构
- 映射你的多租户应用程序用例
- 实现租户隔离
- 定义你想如何管理身份
- 选择合适的授权模型
什么是多租户架构
软件多租户是一种软件架构，在这种架构中，单个实例的软件在一个服务器上运行，并为多个租户服务。以这种方式设计的系统是“共享的”（而不是“专用的”或“隔离的”）。
租户是一组用户，他们共享对软件实例的特定权限的共同访问。
多租户的一个关键心态是“共享”。在多租户的广义定义中，成为多租户应用程序并不意味着解决方案中的每个组件都是共享的。相反，这意味着至少一些解决方案的组件在多个租户之间重复使用。广泛理解这一术语可以更好地帮助你同情客户的需求及其来源。
一旦你了解了多租户架构，下一步是将你的应用程序应用于实际场景，关注特定的产品和 业务需求。
多租户应用程序的用例是什么？
SaaS中的多租户
多租户应用程序通常在商业对商业（B2B）解决方案中找到它们的位置，例如生产力工具、协作软件和其他软件即服务（SaaS）产品。在这种情况下，每个“租户”通常代表一个商业客户，可能拥有多个用户（其员工）。此外，商业客户可能有多个租户以代表不同的组织或业务部门。
通用B2B用例中的多租户
B2B应用程序超越了SaaS产品，并且通常涉及多租户应用程序的使用。在B2B背景下，这些应用程序作为各种团队、商业客户和合作公司访问你的应用程序的共同平台。
例如，考虑一家提供B2C和B2B应用程序的网约车公司。B2B应用程序为多个商业客户服务，采用多租户架构可以帮助管理他们的员工和资源。说明如下，如果公司希望维护一个统一的用户身份系统，它可以设计如下示例中的架构：
Sarah同时拥有个人和商业身份。她作为乘客使用网约车服务，并在空闲时间担任司机。在她的职业角色中，她还管理她的业务，并使用此商业身份与业务1合作。
为什么你应该在SaaS产品中使用多租户
通过多租户扩展
对于企业业务，多租户是有效满足其对可用性、资源管理、成本管理和数据安全需求的关键。从技术层面看，采用多租户方法简化了开发过程，减少了技术挑战，并推动了无缝扩展。
创建统一体验
在研究SaaS产品的根源时，它类似于一个容纳多个公寓的建筑。所有租户共享水、电和燃气等公用设施，但他们独立控制自己空间和资源的管理。这种方法简化了物业管理。
确保通过租户隔离实现安全
在多租户架构中，引入了“租户”一词，以创建边界，将不同租户的资源和数据在共享实例中分隔和保护。这确保了每个租户的数据和操作保持独立和安全，即使他们使用相同的基础资源。
为什么你应该实现租户隔离？
在讨论多租户应用程序时，总是需要实现租户隔离。这意味着在共享系统中（例如，云基础架构或多租户应用程序）分隔和保护不同租户的数据和资源。这可以防止任何未授权的尝试访问其他租户的资源。
虽然解释可能显得抽象，但我们将使用示例和关键细节进一步解释隔离心态以及实现租户隔离的最佳实践 。
租户隔离不违背多租户的“共享”心态
这是因为租户隔离不一定是一个基础设施资源层面的构造。在多租户和隔离领域中，有些人将隔离视为在实际基础设施资源之间的严格划分。这通常导致一个模型，其中每个租户都有单独的数据库、计算实例、帐户或私有云。在共享资源场景中，如多租户应用程序，实现隔离的方法可以是逻辑构造。
租户隔离专注于使用“租户”上下文来限制对资源的访问。它评估当前租户的上下文，并使用该上下文来确定哪些资源对该租户是可访问的。
身份验证和授权不等于“隔离”
使用身份验证和授权来控制访问SaaS环境很重要，但对于完整隔离来说还不够。这些机制只是安全拼图的一部分。
人们经常问一个问题，我可以使用通用授权解决方案和基于角色的访问控制来实现租户隔离吗？
问题在于，你可以构建一个多租户应用程序，但你不能说你实现并采用了租户隔离策略作为最佳实践。我们通常不推荐这样做因为
举个例子，考虑一个你已经为你的SaaS系统设置了身份验证和授权的情况。当用户 登录时，他们收到一个包含他们角色信息的令牌，规定他们可以在应用程序中做什么。这种方法提高了安全性，但并不能确保隔离。
使用“组织”来代表SaaS产品租户，实现租户隔离
仅仅依靠身份验证和授权无法防止具有正确角色的用户访问另一个租户的资源。因此，我们需要引入“租户”上下文，例如租户ID，来限制资源访问。
这就是租户隔离的作用所在。它使用特定租户的标识符来建立边界，就像墙壁、门和锁一样，确保租户之间的明确分隔。
多租户应用程序中的身份管理
我们讨论了租户隔离，那么身份呢？你如何决定你的身份是否应该“隔离”？
在“身份隔离”概念周围经常存在困惑。这可能指的是在一般理解中的一个现实世界的用户具有两个身份的情况。
- 两个身份可以共存于一个身份系统中。例如，Sarah可能有一个个人电子邮件注册，与通过单点登录（SSO）连接的公司电子邮件同时存在。
- 用户在完全独立的产品中维护两个不同的身份，代表完全分开的产品。这些产品彼此完全无关。
有时，这些场景被称为“身份隔离”。然而，这个标签可能对决策没有帮助。
而不是确定你是否需要“身份隔离”，可以考虑
这个答案可以指导你的系统设计。对于多租户应用程序的简要回答，
在多租户应用程序中，身份，与特定租户的资源和数据不同，是在多个租户之间共享的。将自己想象为建筑管理员；你不想维护两个单独的名称表来管理租户的身份。
当目标是实现租户隔离时，你可能已经注意到一直强调的“组织”一词，通常被认为是构建多租户应用程序的最佳实践。
通过使用“组织”的概念，你可以在你的多租户应用程序中实现租户隔离，同时保持统一的身份系统。
如何选择和设计合适的授权模型
在选择合适的授权模型时，考虑以下问题：
- 你是在开发B2C、B2B还是两者结合的产品？
- 你的应用程序是否具有多租户架构？
- 你应用程序中是否有由业务部门决定的某种隔离级别的需求？
- 在组织上下文中需要定义哪些权限和角色，哪些不需要？
Logto中可用的不同授权模型是什么？
基于角色的访问控制
RBAC（基于角色的访问控制）是一种根据用户角色授予权限的方法，可有效管理资源访问。
这种常见技术是访问控制的基础，也是Logto授权功能的关键组成部分。作为一个全面的身份管理平台，Logto为各层和实体提供量身定制的解决方案，适用于开发人员和企业的多种产品架构。
API基于角色的访问控制
为了保护那些不针对任何组织且不需要上下文限制的一般API资源，API RBAC 功能是理想选择。
只需注册API并为每个资源分配权限。然后，通过角色和用户之间的关系来控制访问。
这里的API资源、角色和权限在一个统一的身份系统下“民主化”。这在层次性较弱、不需要非常深隔离级别的B2C产品中是非常常见的。
组织基于角色的访问控制
在B2B和多租户环境中，租户隔离是必要的。为了实现这一点，组织被用作隔离的上下文，这意味着RBAC只有在用户属于特定组织时才有效。
组织RBAC专注于在组织级别而不是API级别控制访问。这为组织级别的自我管理提供了显著的灵活性，但仍在一个统一的身份系统中。
组织RBAC的一个关键特性是，默认情况下，所有组织的角色和权限通常是相同的，这使得Logto的“组织模板”对于提高开发效率极其重要。这与多租户应用程序的共享理念 一致，其中访问控制策略和身份是所有租户（应用程序租户）之间的共同基础设施组件，这是SaaS产品中的一个普遍做法。
结尾
本文提供了准备和配置多租户应用程序所需的一切。今天就试试Logto，开始将组织的最佳实践应用于多租户应用程序开发。