CIAM 101: 身分驗證、身分識別、SSO

背景#

我開始建立 Logto 是因為我注意到身分識別與存取管理（IAM）隨著時間的推移變得越來越複雜且廣泛。IAM 的概念甚至足以衍生出新的概念，如 WIAM（員工 IAM）和 CIAM（顧客 IAM）。

雖然 WIAM 和 CIAM 共享相同的基礎，但它們有不同的用例：WIAM 通常 用於內部用戶，而 CIAM 用於外部顧客。 一些例子：

• WIAM 你的公司為員工設有統一的身分系統，因此每個人都可以使用相同的帳戶訪問公司資源，如軟體訂閱、雲端計算服務等。
• CIAM 你的線上書店需要為顧客和賣家提供一個用戶身分系統。登入體驗是註冊的關鍵部分，因為它位於轉換漏斗的頂端。

Logto 出於多種原因開始了 CIAM（我們會有另一篇文章討論這個）。在開發過程中，我們意識到在團隊中建立統一的理解會對我們的產品升級有幫助。我們希望這也能幫助你更好地了解 IAM 的領域。

讓我們開始吧！

CIAM 的基礎#

在本文中，我們將專注於 CIAM 的基本概念以及我們在身分驗證流程中可能遇到的問題。我們還將討論單一登入（SSO）及其相關場景。

身分驗證和授權#

💡 身分驗證最初被定義為“你是誰？”。然而，當討論數位身分時，通過“證明擁有身分”來示範身分驗證更正確。（感謝 Calm-Card-2424）

如果發現某些東西不屬於這兩个類別中的任何一項，它很可能不是身分业务的重點。

• 身分驗證的例子
  • 密碼登入、無密碼登入、社會登入等。
  • 機器對機器的驗證
• 授權的例子
  • 基於角色的訪問控制
  • 基於屬性的訪問控制
• 例外的例子
  • 非身分數據
  • Web 鉤子

身分和租戶#

身分通常代表用戶或機器。在成功驗證後，會出具 ID 令牌作為身分證明。

換句話說，驗證的主要目的是獲得身分。

租戶是一組身分：

當我們討論“多租戶”時，我們指的是多個 Logto 實例，它們在身分上互相隔離。換句話說，多個 Logto 實例。

注意這裡有兩個隔離的身分系統，也就是說，即使是相同的識別符（如電子郵件、電話等），你也不能在租戶 2 中使用租戶 1 的身分。這就像你的 Costco 會員資格無法在 Whole Foods 使用。

應用和租戶#

就像身分一樣，應用也屬於某個租戶。記住幾點：

• 應用和身分之間通常沒有直接關係。
  • 身分可以代表應用，但兩者之間沒有直接連結。
• 像用戶一樣，應用也位於租戶層級。
• 應用是代碼，而用戶是人類。
• 應用的唯一目的是完成驗證，也就是獲得身分。

身分提供者（IdP）和服務提供者（SP）#

這兩者之間的區別很棘手，但卻很重要。

• 身分提供者 是提供驗證（AuthN）並發行身分的服務。

你可以從 Google 找到各種服務提供者的解釋，但它們可能不夠滿意。在我看來，服務提供者是一個相對的概念：

• **服務提供者（或在 OIDC 中稱為依賴方）**是一個啟動驗證（AuthN）並從身分提供者請求結果的服務或客戶端。

小測驗#

考慮一個典型的社會登入場景：

❓ 在這個圖中有多少個服務提供者和身分提供者？

答案

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

案例研究：一家科技解決方案公司#

你是一家科技解決方案公司的 CTO，你有超過 100 個業務合作夥伴，你已經交付了超過 300 個項目。

• 每個項目都是一個帶後端服務的網頁應用或移動應用。
• 對於每個業務合作夥伴，你想重新設計用戶系統以提供項目之間的 SSO。

❓ Logto（或一個 CIAM 產品）可以怎樣幫忙？

答案

為每個業務合作夥伴創建一個 Logto 實例。每個合作夥伴擁有一個租戶。項目在 Logto 中映射為“應用”。

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 中，看起來也是一樣，但我們懷疑其背後使用了不同的身分，因為我們需要為每一個工作區創建一個新帳戶。

Notion 提供“個人計劃”，這通常是在內部作為一個組織實現的，內部有唯一的用戶（你）。我們不知道 Notion 的具體實現，但這一解釋對於我們的模型來說是合理且可行的。

每個組織也有一個識別符，通常稱為“組織域”。

小測驗#

❓ 應用可以與組織相關聯嗎？

答案

當然可以。我們在開始時討論過，應用可以擁有身分。你能舉例說明一個商業場景嗎？

留下的問題#

3. 應該在不同企業 SSO 客戶之間隔離數據嗎？

• 是： 在組織層級隔離業務數據，如消息和文件。
• 否： 保持身分獨立，因為它們不需要與組織相關聯。
• 注意這裡涉及到三個不同的實體：身分、組織和企業 SSO 配置；這顯著增加了複雜性。問題本身並不夠具體。

4. 是否需要為企業 SSO 管理員提供一個儀表板來查看活躍用戶、審計日誌等？

5. 如何在用戶從企業 SSO 身分提供者中被移除時自動停用帳戶？

• 這些需求更偏向業務導向，可以在組織層級實現。我們在這裡暫時保留開放。

結語#

我們介紹了幾個概念：身分驗證（AuthN）、授權（AuthZ）、身分、租戶、應用、身分提供者（IdP）、服務提供者（SP）、單一登入（SSO）和企業 SSO（組織）。理解這些概念可能需要一些時間。

在寫這篇文章時，我發現有趣的是，線上服務中最昂貴的計劃通常包括與授權相關的獨特功能，這在本文中完全未被提及。你可能已經對授權有一些疑問，例如：

• 我們如何分配并驗證用戶的權限？
• 應該使用哪種授權模型？
• 應用授權模型的最佳實踐是什麼？