繁體中文（香港）

ciam
auth
authentication

CIAM 101: 驗證、身份、SSO

Logto 因為各種原因開始瞭解 CIAM（我們將有另一篇文章來探討這個話題）。在開發過程中，我們意識到在團隊中建立一個統一的理解是有益的，這樣在將我們的產品提升到下一個層次之前就能夠受益。我們希望這也能幫助你更好地理解 IAM 的全貌。

Gao

Founder

11/28/2022

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

背景

我開始構建 Logto 是因為我注意到身份和訪問管理 (IAM) 隨著時間變得越來越複雜和龐大。IAM 的概念足夠大，以至於產生了新的概念，例如 WIAM（員工 IAM）和 CIAM（客戶 IAM）。

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

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

我們開始吧！

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。下圖顯示了兩者的區別：

社交登入

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 的客戶時，手動管理映射是可以的。然而，仍然需要考慮更多因素：

如果有數百或數千個企業 SSO 客戶怎麼辦？
“普通用戶”和“企業 SSO 用戶”之間有什麼聯系？
是否需要隔離不同企業 SSO 客戶之間的數據？
是否需要為企業 SSO 管理員提供一個儀表板來查看活躍用戶、審計日誌等？
當用戶被企業 SSO 身份提供者移除時如何自動停用帳戶？

還有很多。由於幾乎所有企業 SSO 都是基於電子郵件域的，我們可以迅速找出一個更好的解決方案：

如果用戶可以證明擁有該域，他們可以以自助方式設置該域的企業 SSO。

這個解決方案解決了前兩個問題：

1. 如果有數百或數千個企業 SSO 客户怎麼辦？

他們可以自助配置企業 SSO。

2. “普通用戶”和“企業 SSO 用戶”之間有什麼聯系？

開放所有可能的登入方式給普通用戶，除了企業 SSO；而限制登錄方法給試圖用配置好的域登錄的用戶。

至於第三個問題：

3. 是否需要隔離不同企業 SSO 客户之間的數據？

是的也不是。該談談組織了。

組織

我們提到了使用電子郵件域來識別使用的特定企業 SSO 方法；換句話說，對特定用戶組進行特定處理。

但是，客戶的要求通常不僅僅是企業 SSO；例如，上節中的問題 4 和 5。多年來，傑出的 SaaS 公司已經開發出了一個成熟的模型來解決此類問題：組織。

組織規則

組織是一組身份，通常小於租戶。
所有組織都與一個租戶相關聯。

你可以看到其他術語，如“工作空間”、“團隊”或甚至“租戶”在軟件中。要識別它是否是我們正在討論的概念，請檢查它是否代表“身份的群组”。

在本文中，為了統一，我們使用“組織”這個詞。

在 Notion 中，你可以使用相同的電子郵件地址創建並加入多個工作空間（即組織），並輕易在它們之間進行切換。

對於 Slack，看起來一樣，但我們懷疑它在背後使用不同的身份，因為我們需要為每個工作空間創建一個新賬號。

Slack workspaces

Slack 工作空間

Notion workspaces

Notion 工作空間

Notion 提供了一個“個人計劃”，通常是在幕後的工作空間，有唯一的用戶（你）在其中。我們不知道 Notion 的確切實現，但這個解釋對於我們的模型是合理而可行的。

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

小測驗

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

答案

可以的。我們在開始時討論過，一個應用可以有一個身份。你能舉出一個具體業務情景嗎？

未解決的問題

3. 是否需要隔離不同企業 SSO 客户之間的數據？

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

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

5. 當用戶被企業 SSO 身份提供者移除時，如何自動停用賬戶？

這些需求更傾向於業務，並可以在組織級別實現。這裡我們留待開放。

結尾備註

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

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

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

背景#

CIAM 的基礎#

驗證和授權#

身份和租戶#

應用和租戶#

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

小測驗#

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

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

SSO 情況 1#

SSO 情況 2#

SSO 情況 3#

SSO 映射#

組織#

小測驗#

未解決的問題#

結尾備註#

背景#

CIAM 的基礎#

驗證和授權#

身份和租戶#

應用和租戶#

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

小測驗#

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

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

SSO 情況 1#

SSO 情況 2#

SSO 情況 3#

SSO 映射#

組織#

小測驗#

未解決的問題#

結尾備註#

背景

CIAM 的基礎

驗證和授權

身份和租戶

應用和租戶

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

小測驗

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

我們談論 SSO 時在談論什麼

SSO 情況 1

SSO 情況 2

SSO 情況 3

SSO 映射

組織

小測驗

未解決的問題

結尾備註

背景

CIAM 的基礎

驗證和授權

身份和租戶

應用和租戶

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

小測驗

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

我們談論 SSO 時在談論什麼

SSO 情況 1

SSO 情況 2

SSO 情況 3

SSO 映射

組織

小測驗

未解決的問題

結尾備註