## 背景我開始建立 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 令牌作為身分證明。換句話說，驗證的主要目的是獲得身分。租戶是一組身分： ```mermaid graph TD Tenant --- A[Identity: 用戶 1] Tenant --- B[Identity: 用戶 2] Tenant --- C[Identity: 機器 1] ``` 當我們討論“多租戶”時，我們指的是多個 Logto 實例，它們在身分上互相隔離。換句話說，多個 Logto 實例。 ```mermaid graph TD T1[租戶 1] --- A[身分: 用戶 1] T2[租戶 2] --- B[身分: 用戶 1] T2[租戶 2] --- C[身分: 機器 1] subgraph IS2[身分系統 2] T2 B C end subgraph IS1[身分系統 1] T1 A end ``` 注意這裡有兩個**隔離的**身分系統，也就是說，即使是相同的識別符（如電子郵件、電話等），你也不能在租戶 2 中使用租戶 1 的身分。這就像你的 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 應用] --> |啟動登入| Logto --> |重定向| GitHub GitHub --> |返回 GitHub 身分| Logto --> |返回 Logto 身分| A ``` **❓ 在這個圖中有多少個服務提供者和身分提供者？**

答案

兩者都有兩個。對 Logto 來說，iOS 應用是服務提供者，而 Logto 是身分提供者。對 GitHub 來說，Logto 是服務提供者，而 GitHub 是身分提供者。因此，Logto 同時是一個服務提供者和身分提供者。

## 案例研究：一家科技解決方案公司你是一家科技解決方案公司的 CTO，你有超過 100 個業務合作夥伴，你已經交付了超過 300 個項目。 - 每個項目都是一個帶後端服務的網頁應用或移動應用。 - 對於每個業務合作夥伴，你想重新設計用戶系統以提供項目之間的 SSO。 **❓ Logto（或一個 CIAM 產品）可以怎樣幫忙？**

答案

為每個業務合作夥伴創建一個 Logto 實例。每個合作夥伴擁有一個租戶。項目在 Logto 中映射為“應用”。 ```mermaid graph TD T1[租戶 1] --- A[應用 1] T1 --- B[應用 2] T1 --- C[應用 3] T1 --- U1[用戶 1] T1 --- U2[用戶 2] T2[租戶 2] --- D[應用 1] T2 --- E[應用 2] T2 --- U21[用戶 1] T2 --- U22[用戶 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。這是 SSO 在 CIAM 中最常見的用例。讓我們仔細看看。如果我們想使用 @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 中見！