## 背景我開始構建 Logto 是因為我注意到身份和訪問管理 (IAM) 隨著時間變得越來越複雜和龐大。IAM 的概念足夠大，以至於產生了新的概念，例如 WIAM（員工 IAM）和 CIAM（客戶 IAM）。雖然 WIAM 和 CIAM 有相同的基礎，但它們有不同的使用場景：WIAM 通常用於內部用戶，而 CIAM 用於外部客戶。一些例子： - **WIAM** 你的公司有一個統一的身份系統給員工，因此每個人都可以使用相同的帳戶訪問公司資源，比如軟件訂閱、雲計算服務等。 - **CIAM** 你的在線書店需要一個用戶身份系統給客戶和賣家。登錄體驗是用戶上線的關鍵部分，因為它位於轉化漏斗的頂端。 Logto 因為各種原因開始瞭解 CIAM（我們將有另一篇文章來探討這個話題）。在開發過程中，我們意識到在團隊中建立一個統一的理解是有益的，這樣在將我們的產品提升到下一個層次之前就能夠受益。我們希望這也能幫助你更好地理解 IAM 的全貌。我們開始吧！ ## CIAM 的基礎不論它們的差異，WIAM 和 CIAM 都有相同的基礎：驗證（authentication）和授權（authorization）。這兩個概念是其特徵的核心。在這篇文章中，我們將重點討論 CIAM 的基本概念以及在或之後驗證流程中可能遇到的問題。我們還將討論單一登錄（SSO）及其相關情景。 ### 驗證和授權 - 驗證（AuthN）回答“你擁有哪個身份？” - 授權（AuthZ）回答“你可以做什麼？” > 💡 驗證最初被定義為“你是誰？”。然而，當談論數字身份時，通過“證明身份的所有權”來展示驗證會更準確。（致謝 [Calm-Card-2424](https://www.reddit.com/r/programming/comments/10uycg0/comment/j7eyhrb/)）如果你發現某些東西不屬於這兩個類別中的任一項，那麼它可能對身份業務來說並非必要。 - **身份驗證的例子** - 密碼登錄、無密碼登錄、社交登錄等。 - 機器對機器驗證 - **授權的例子** - 基於角色的訪問控制 - 基於屬性的訪問控制 - **例外的例子** - 非身份數據 - 網絡鉤子 ### 身份和租戶身份通常代表用戶或機器。成功驗證後，會發行一個身份 ID Token。換句話說，認證的主要目的是獲得一個身份。租戶是身份的集合： ```mermaid graph TD Tenant --- A[身份：用戶 1] Tenant --- B[身份：用戶 2] Tenant --- C[身份：機器 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 ``` 請注意，它有兩個**隔離的**身份系統，即使對於相同的識別符（電子郵件、電話等），你也不能在租戶 1 中使用租戶 2 的身份。這就像你的 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 ID| Logto --> |返回 Logto ID| A ``` **❓ 在這個圖中，有多少服務提供者和身份提供者？**

答案

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

## 案例研究：一家技術解決方案公司你是一家技術解決方案公司的 CTO，擁有超過 100 位商業合作伙伴，並已交付了超過 300 個項目。 - 每個項目都是一個 web 應用或帶有後端服務的移動應用。 - 對於每個商業合作夥伴，你都希望重構用戶系統以提供跨項目的 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 不等於“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，看起來一樣，但我們懷疑它在背後使用不同的身份，因為我們需要為每個工作空間創建一個新賬號。

![Slack workspaces](https://uploads.strapi.logto.io/1/slack_workspaces_b4f0bcc978.png) _Slack 工作空間_ ![Notion workspaces](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！