繁體中文（台灣）

ciam
auth
authentication

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

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

Gao

Founder

11/28/2022

不要在使用者認證上浪費數週時間

使用 Logto 更快地發布安全應用程式。幾分鐘內整合使用者認證，專注於您的核心產品。

立即開始

背景

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

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

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

讓我們開始吧！

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

社交登入

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；而我們僅限制企業 SSO 用戶使用配置的域進行登入。

至於第三個問題：

3. 應該隔離不同企業 SSO 客戶之間的数据吗？

是和否。該引入組織概念了。

組織

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

然而，客戶的需求往往不僅限於企業 SSO；例如，前面部分列出的問題 4 和 5。多年來，傑出的 SaaS 公司已經發展出一個成熟的模型來解決這些問題：組織。

組織規則

一個組織是一組身分，通常比租戶小。
所有組織都與一個租戶相關。

你可能會看到其他術語，如“工作區”、“團隊”或甚至“租戶”在軟體中。要識別它是否是我們正在討論的概念，只需檢查它是否代表“ 一組身分”。

在本文中，我們將使用術語“組織”以保持一致性。

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

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

Slack 工作區

Slack 工作區

Notion 工作區

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 映射

組織

小測驗

留下的問題

結語