## 背景我开始构建 Logto 是因为我注意到身份和访问管理（IAM）随着时间的推移变得越来越复杂和庞大。IAM 的概念甚至足够大，以至于引出了新的概念，例如 WIAM（工作团队 IAM）和 CIAM（客户 IAM）。虽然 WIAM 和 CIAM 共享相同的基础，但它们有不同的用例：WIAM 通常用于内部用户，而 CIAM 用于外部客户。一些例子： - **WIAM** 你的公司有一个统一的身份系统供员工使用，因此每个人都可以用相同的账户访问公司资源，如软件订阅、云计算服务等。 - **CIAM** 你的在线书店需要一个用户身份系统供客户和卖家使用。登录体验是上手的关键环节，因为它位于转换漏斗的顶部。 Logto 因各种原因从 CIAM 开始（我们会在另一篇文章中讨论）。在开发过程中，我们意识到建立团队内部统一的理解会对我们将产品提升到下一个层次有帮助。我们希望这也能帮助你更好地理解 IAM 的全貌。让我们开始吧！ ## CIAM 的基础无论它们的差异如何，WIAM 和 CIAM 都有相同的基础：认证和授权。这两个概念是它们特性的核心。在本文中，我们将重点关注 CIAM 的基本概念以及我们可能在认证流程中或之后遇到的问题。我们还将讨论单点登录（SSO）及其相关场景。 ### 认证和授权 - 认证（AuthN）回答“你拥有哪个身份？” - 授权（AuthZ）回答“你可以做什么？” > 💡 认证最初定义为“你是谁？”。然而，当讨论数字身份时，证明身份所有权更为准确。正如 [Calm-Card-2424](https://www.reddit.com/r/programming/comments/10uycg0/comment/j7eyhrb/) 所言。如果你发现一些不属于这两个类别的东西，那它很可能不是身份业务中必需的。 - **认证的例子：** - 密码登录、无密码登录、社交登录等。 - 机器对机器认证 - **授权的例子：** - 基于角色的访问控制 - 基于属性的访问控制 - **例外的例子：** - 非身份数据 - Web 钩子 ### 身份和租户身份通常代表用户或机器。成功认证后，会发放一个 ID Token 作为身份。换句话说，认证的主要目的是获取一个身份。租户是一组身份： ```mermaid graph TD Tenant --- A[Identity: User 1] Tenant --- B[Identity: User 2] Tenant --- C[Identity: Machine 1] ``` 当我们讨论“多租户”时，我们指的是多个 Logto 实例，它们的身份相互隔离。换句话说，就是多个 Logto 实例。 ```mermaid graph TD T1[Tenant 1] --- A[Identity: User 1] T2[Tenant 2] --- B[Identity: User 1] T2[Tenant 2] --- C[Identity: Machine 1] subgraph IS2[Identity system 2] T2 B C end subgraph IS1[Identity system 1] T1 A end ``` 注意，它有两个**独立的**身份系统，即使是相同的标识符（电子邮件、电话等），你也不能在租户 1 中使用租户 2 的身份。这就像你的 Costco 会员资格在 Whole Foods 无效一样。 🧱 简而言之，租户之间有“物理隔墙”。租户的定义在不同的 CIAM 产品中各不相同。在 Logto 中，它有时被称为“组织”，我们将在稍后介绍。 ### 应用和租户就像身份一样，应用也属于一个租户。要记住的几件事： - 应用和身份之间通常没有直接关系。 - 身份可以代表应用，但它们之间没有直接联系。 - 像用户一样，应用也在租户级别。 - 应用是代码，而用户是人类。 - 应用的唯一目的是完成认证，即获取一个身份。 ### 身份提供者（IdP）和服务提供者（SP）这两个提供者之间的区别棘手但重要。 - **身份提供者** 是一个提供认证（AuthN）并颁发身份的服务。你可以从 Google 中找到各种关于服务提供者的解释，尽管它们可能不那么令人满意。在我看来，服务提供者是一个相对的概念： - **服务提供者（或 [OIDC](https://openid.net/specs/openid-connect-core-1_0.html) 中的依赖方）** 是一个发起认证（AuthN）并请求身份提供者结果的服务或客户端。 #### 小测验考虑一个典型的社交登录场景： ```mermaid graph LR A[iOS App] --> |调用登录| Logto --> |重定向| GitHub GitHub --> |返回 GitHub ID| Logto --> |返回 Logto ID| A ``` **❓ 在这个图中有多少服务提供者和身份提供者？**

答案

两者都有两个。iOS App 对 Logto 来说是服务提供者，而 Logto 是身份提供者。Logto 对 GitHub 来说是服务提供者，而 GitHub 是身份提供者。因此，Logto 既是服务提供者也是身份提供者。

## 案例研究：一家技术解决方案公司你是一家技术解决方案公司的 CTO，你有超过 100 个业务合作伙伴，并交付了超过 300 个项目。 - 每个项目要么是一个 web 应用程序，要么是一个带有后端服务的移动应用程序。 - 对于每个业务合作伙伴，你希望重构用户系统以提供跨项目的 SSO。 **❓ Logto（或 CIAM 产品）如何提供帮助？**

答案

为每个业务合作伙伴创建一个 Logto 实例。每个伙伴持有一个租户。项目映射到 Logto 中的“应用”。 ```mermaid graph TD T1[Tenant 1] --- A[App 1] T1 --- B[App 2] T1 --- C[App 3] T1 --- U1[User 1] T1 --- U2[User 2] T2[Tenant 2] --- D[App 1] T2 --- E[App 2] T2 --- U21[User 1] T2 --- U22[User 2] ``` Logto 提供一个在租户内的统一登录体验（即 SSO），因此用户在访问同一租户中的其他应用时，无需再次登录。

## 我们谈论 SSO 时谈论什么我们发现“SSO”这个术语常常引起混淆。我们认为单点登录（SSO）是一种行为，而不是一个业务概念。因此，SSO 与“WIAM 中的 SSO”不等同。当我们说“需要 SSO”时，它可能指以下情况之一： ### SSO 情况 1 > 👉🏽 在一家大公司，员工使用相同的凭据登录所有公司授权的资源（如电子邮件、即时通讯、云服务等）。这是一种典型的 WIAM 场景。在这种情况下，只有一个身份提供者涉及。我们现在不关心。 ### SSO 情况 2 > 👉🏽 最终用户使用相同的凭据登录同一公司开发的所有服务（如 GSuite）。 Logto 目前专注于上述方法。可能存在多个外部身份提供者，例如第三方社交登录提供者，彼此独立且无关联。尽管如此，Logto 仍然是身份的唯一真实来源，只是从其他提供者那里“借用”它们。在这种情况下，Logto 既是身份提供者（对 GSuite 应用来说），也是服务提供者（对外部身份提供者而言）。 ### SSO 情况 3 > 👉🏽 最终用户只能使用特定电子邮件域内的身份提供者完成认证。例如，用 Google Workspace 登录 Figma。这是最常见的 CIAM 中的 SSO 用例。让我们更仔细地看看。如果我们想使用 @silverhand.io 邮箱登录 Figma，可以使用社交登录或 SSO。下图说明了两者之间的区别：

用语言描述： - 在社交登录后，用户可以自行设置密码或更改 Figma 中的邮箱地址。 - 在 SSO 之后，用户不能设置密码或更改任何个人信息，包括邮箱地址，因为其身份由 Google Workspace 管理。在这种情况下，Logto 是身份提供者和服务提供者。看来 SSO 比普通登录过程更复杂。对身份拥有者有什么好处呢？ - **集中控制：** 在一个地方维护身份信息和认证过程，确保用户信息始终更新。没有必要在不同应用中为更改添加或删除许可证。 - **改善用户体验：** 需要 SSO 的身份拥有者通常是公司。员工可以使用相同的凭据和共享的会话来使用跨公司的应用，例如 Figma、Zoom、Slack 等。 - **增强安全性：** 你可能已经注意到一些公司要求使用特定的登录方法，例如动态验证码。使用 SSO 可以确保每位员工使用相同的登录方法组合来访问所有资源。 > 🤔 聪明的你一定注意到了，这实际上是从 SaaS 角度来看**SSO 情况 1**。是时候讨论 SSO 图中的“X”了。这表示 Figma 连接邮箱域到特定身份提供者的过程。那么，它是如何工作的呢？ ## SSO 映射由于请求通常来自企业客户，我们将“SSO 情况 3”中的过程称为“企业 SSO”以明确。我们可以轻松设计一个简单的解决方案：创建一个邮箱域和 SSO 方法之间的映射，然后手动更新它。过程“X”的动作现在很清楚： > 🔍 **找到给定邮件域的映射企业 SSO 方法** 因此，如果你将 `silverhand.io` 配置为有效的邮箱域，与 Google Workspace SSO URL 相连，那么尝试使用 `@silverhand.io` 邮箱登录的用户将被重定向到相应的 Google Workspace 登录页面，而不是在站点内处理。当你只有几十个需要企业 SSO 的客户时，手动管理映射还可以。然而，还有更多考虑因素： 1. _如果有数百甚至数千个企业 SSO 客户呢？_ 2. _“普通用户”和“企业 SSO 用户”之间有什么关系？_ 3. _应否在不同的企业 SSO 客户之间隔离数据？_ 4. _是否需要为企业 SSO 管理员提供一个仪表板，以查看活跃用户、审核日志等？_ 5. _当用户从企业 SSO 身份提供者中删除时，如何自动停用账号？_ 还有很多。由于几乎所有企业 SSO 都基于邮件域，因此我们可以很快找到一个更好的解决方案： - 如果用户可以证明该域的所有权，他们可以以自助方式设置该域的企业 SSO。此解决方案解决了前两个问题： > _1. 如果有数百甚至数千个企业 SSO 客户呢？_ - 他们可以以自助方式配置企业 SSO。 > _2. “普通用户”和“企业 SSO 用户”之间有什么关系？_ - 我们向普通用户开放所有可能的登录方法，除企业 SSO 外；而我们将登录方法限制为仅尝试使用配置域登录的用户使用企业 SSO。至于第三个问题： > _3. 应否在不同的企业 SSO 客户之间隔离数据？_ - 是与否。该引入组织了。 ## 组织我们提到了使用电子邮件域来识别要使用的特定企业 SSO 方法；换句话说，为特定批量的用户应用特定处理。然而，客户的需求通常不只是企业 SSO，例如上节中的问题 4 和 5。多年来，出色的 SaaS 公司开发了一个成熟的模型来解决这些问题：组织。 **组织规则** 1. 一个组织是一组身份，通常比一个租户小。 2. 所有组织都与一个租户相关联。你可能会看到其他术语，如“工作空间”、“团队”，甚至“租户”在软件中使用。要判断它是否是我们在讨论的概念，只需检查它是否代表“一组身份”。在本文中，我们将使用“组织”一词以保持一致。 🤹🏽‍♀️ 在大多数情况下，“一组身份”等同于“一组用户”。然而，**相同的身份可以存在于多个组织中**。在 Notion 中，你可以创建和加入多个工作空间（即组织），使用相同的邮箱地址并轻松地在它们之间切换。对于 Slack，它看起来是一样的，但我们怀疑背后使用不同的身份，因为我们需要为每个工作空间创建一个新账号。

![Slack 工作空间](https://uploads.strapi.logto.io/1/slack_workspaces_b4f0bcc978.png) _Slack 工作空间_ ![Notion 工作空间](https://uploads.strapi.logto.io/1/notion_workspaces_5bdc2b7e9b.png) _Notion 工作空间_

Notion 有一个“个人计划”可用，它通常是表面上的一个组织，且里面只有唯一的用户（你）。我们不知道 Notion 的确切实施，但这解释是合理的，并在我们的模型中实现。每个组织也有一个标识符，通常被称为“组织域”。 “组织域”是用于区分组织的内部标识符。它可能与“邮件域”不同，因为前者由服务提供者管理，而后者通常由外部身份提供者提供。例如，你可以在 Slack 中使用 `foo` 作为组织域，但为此组织使用 `@bar.io` 作为邮件域。 ### 小测验 **❓ 一个应用可以与一个组织关联吗？**

答案

是的，是的。如我们在开头讨论的，一个应用可以有一个身份。你能举例说明这样的业务场景吗？

## 仍然存在的问题 > _3. 应该在不同的企业 SSO 客户之间隔离数据吗？_ - **是：** 在组织级别隔离业务数据，如信息和文档。 - **否：** 保持身份独立，因为它们无需与组织关联。 - 注意这涉及三个不同的实体：身份、组织和企业 SSO 配置；这显然增加了复杂性。问题本身不够具体。 > _4. 是否需要为企业 SSO 管理员提供一个仪表板，以查看活跃用户、审核日志等？_ > > _5. 当用户从企业 SSO 身份提供者中删除时，如何自动停用账号？_ - 这些需求更偏向于业务层，可以在组织层面实现。我们将在这里保持开放。 ## 结束语我们介绍了几个概念：认证 (AuthN)、授权 (AuthZ)、身份、租户、应用程序、身份提供者 (IdP)、服务提供者 (SP)、单点登录 (SSO) 和企业 SSO (组织)。理解它们可能需要一点时间。在写这篇文章时，我注意到有趣的是，在线服务中最昂贵的计划通常包括与授权相关的专属功能，这在本文中被完全忽略了。你可能已经对授权产生了一些疑问，比如： - 我们如何为用户分配权限并验证它们？ - 我应该使用什么样的授权模型？ - 应用授权模型的最佳实践是什么？ 🔥 休息一下，在 CIAM 102 再见！