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）

如果你發現某些東西不屬於這兩個類別中的任一項，那麼它可能對身份業務來說並非必要。

• 身份驗證的例子
  • 密碼登錄、無密碼登錄、社交登錄等。
  • 機器對機器驗證
• 授權的例子
  • 基於角色的訪問控制
  • 基於屬性的訪問控制
• 例外的例子
  • 非身份數據
  • 網絡鉤子

身份和租戶#

身份通常代表用戶或機器。成功驗證後，會發行一個身份 ID Token。換句話說，認證的主要目的是獲得一個身份。租戶是身份的集合：

當我們討論“多租戶”時，我們指的是多個 Logto 實例，這些實例在身份上彼此隔離。換句話說，是多個 Logto 實例。

請注意，它有兩個隔離的身份系統，即使對於相同的識別符（電子郵件、電話等），你也不能在租戶 1 中使用租戶 2 的身份。這就像你的 Costco 會員資格在 Whole Foods 無效一樣。

應用和租戶#

就像身份一樣，應用也屬於租戶。有幾件事情要記住：

• 一般來說，應用和身份之間沒有直接關係。
  • 身份可以代表應用，但它們之間沒有直接連接。
• 像用戶一樣，應用也是租戶級別的。
• 應用是代碼，而用戶是人類。
• 應用的唯一目的是完成認證，獲取一個身份。

身份提供者 (IdP) 和服務提供者 (SP)#

這兩個提供者之間的區別很重要，但也很微妙。

• 身份提供者 是提供認證 (AuthN) 並發行身份的服務。

你可以從 Google 找到關於服務提供者的不同解釋，但它們可能不夠滿意。在我的腦海中，服務提供者是一個相對的概念：

• 服務提供者（或 OIDC 中的依賴方） 是 發起認證（AuthN）並從身份提供者請求結果的服務或客戶端。

小測驗#

考慮一個典型的社交登錄場景：

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

答案

兩者都有兩個。iOS 應用是 Logto 的服務提供者，而 Logto 是身份提供者。 Logto 也是 GitHub 的服務提供者，而 GitHub 是身份提供者。因此，Logto 既是服務提供者， 也是身份提供者。

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

你是一家技術解決方案公司的 CTO，擁有超過 100 位商業合作伙伴，並已交付了超過 300 個項目。

• 每個項目都是一個 web 應用或帶有後端服務的移動應用。
• 對於每個商業合作夥伴，你都希望重構用戶系統以提供跨項目的 SSO。

❓ Logto（或 CIAM 產品）如何幫助？

答案

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

Logto 在一個租戶內提供通用的登錄體驗（即 SSO），所以用戶在同一租戶中的另一個應用中不需要再次登錄。

我們談論 SSO 時在談論什麼#

我們發現“SSO”這個術語經常引起混淆。我們認為單一登錄 (SSO) 是一種行為，而不是商業概念。因此，SSO 不等於“SSO 在 WIAM 中”。

當我們說“需要 SSO”時，它可能指以下情況之一：

SSO 情況 1#

👉🏽 在一家大公司，員工使用相同的憑據登錄所有公司許可資源（例如電子郵件、IM、云服務）。

這是典型的 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；而限制登錄方法給試圖用配置好的域登錄的用戶。

至於第三個問題：

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 (組織)。理解這些概念可能需要一些時間。

在寫這篇文章時，我注意到，有趣的是，企業服務的最昂貴方案通常包含與授權相關的專屬功能，這在本文中完全未提及。你可能已經對授權產生了一些疑問，如：

• 我們如何賦予用戶權限並驗證它們？
• 我應該使用哪個授權模型？
• 在應用授權模型時的最佳實踐是什麼？