規劃你的架構
為了在設計和規劃架構時建立最佳實踐，請從不同角度考慮你的需求。專注於最終目標和工作流程，而不僅僅是底層技術和功能。以下是一些關鍵問題，可以指導和啟發你為產品構建理想的架構。
你的商業模式是什麼，涉及哪些關鍵方和利益相關者？
通常有兩種主要的商業模式，B2C 和 B2B，每種模式在複雜的身分管理場景中涉及不同的方。了解這些關鍵利益相關者有助於你設計出提供以使用者為中心的體驗並涵蓋所有身分管理方面的系統。
B2C
在 B2C 應用程式中，身分管理通常比較簡單，通常只涉及兩方。
開發者（你）
這指的是 Logto Console 管理員和協作者——通常是你和你的開發團隊——管理和保護使用者身分池，並直接與身分資料庫合作。你可以直接在 Logto Console 中管理客戶身分，或使用 Logto Management API 進行自訂開發。
你的消費者
你的消費者是儲存在 Logto 核心服務和資料庫中的使用者身分。在 B2C 模式中，消費者可以管理自己的驗證和個人資訊。
B2B
在 B2B 應用程式中，這個架構中引入了另一層和上下文。業務單位所有者（或組織）控制誰可以訪問他們的實例、如何驗證以及他們可以做什麼。組織管理所有訪問其實例的終端使用者的身分。
開發者（你）
這仍然指的是 Logto Console 管理員和協作者。儘管組織管理員可以管理身分，但開發者仍然可以直接在 Logto Console 中管理客戶身分，或通過使用 Logto Management API 進行自訂開發。
你的客戶（組織管理員）
你的客戶是代表多租戶應用程式中「組織」的業務單位，例如 Slack 或 Notion 中的 工作區。每個工作區通常有多個角色和一個或多個管理員來管理員工或使用者。在以下內容中，我們將能夠管理成員身分的人稱為「組織管理員」。
你的客戶的員工、合作夥伴或消費者
這些是終端使用者身分，在組織上下文中稱為「成員」，可以在組織內進行管理。雖然這些身分由組織分隔，但它們都聚合在單一身分系統下。
在現實場景中，從產品角度來看，這些可能是公司員工、業務合作夥伴，甚至是與組織相關的消費者。
其他
其他模型，如 B2B2C，可能由於其複雜性而從這兩者中衍生出來。然而，方法保持不變：所有變化都源自相同的核心基礎。
在下一章中，我們將詳細介紹這兩種常見架構，並強調 Logto 支援的相關功能。
提煉你的驗證 (Authentication) 需求
一旦你了解了技術和產品設計中涉及的關鍵使用者和方，請考慮以下問題來完善你的身分架構，並確定你的驗證 (Authentication) 需求和控制層級：
-
客戶在驗證和登入體驗方面有哪些選擇？這通常取決於你的業務、獲客策略和產品需求。
例如：我的應用程式需要哪些功能？社交登入？無密碼登入？
-
你（開發者）希望對客戶行為有多大控制權？
例如：客戶可以更新和維護他們的個人資料嗎？客戶可以自行開啟和關閉 MFA 嗎？他們可以選擇偏好的登入方式嗎？
-
你希望將哪些類型的自訂權限委派給組織？這取決於你的產品領域和行業以及客戶的具體需求，可能因組織而異。
例如：每個組織的登入體驗應該有所不同嗎？如果是，應該僅限於品牌自訂，還是應包括驗證流程的差異？
-
你希望組織管理員對其成員行為有多大控制權？
例如：組織管理員應該能夠決定是否需要 MFA 嗎？管理員應該有能力更改成員的密碼嗎？
你需要單一通用身分系統還是多個獨立的系統？
另一個需要記住的關鍵問題是問自己，你或你的業務或產品的某個部分是否需要一個身分系統或多個獨立的系統。
通常，答案是一個單一的通用身分系統，這意味著你只需要一個 Logto 租戶（或在 Logto OSS 中的一個 Logto 管理控制台實例）。Logto 被設計為支援在單一租戶中管理多個應用程式和多個組織。一個生產環境的 Logto 租戶通常足以滿足大多數需求。以下是你可能面臨的一些常見情況：
我想構建一個具有多租戶的 SaaS 應用程式
如果你正在構建一個具有「工作區」或「組織」概念的 SaaS 應用程式，為每個客戶提供服務，你可以使用組織來管理單一租戶中的每個客戶工作區。
在這種情況下，使用者可以是多個組織的成員。例如，使用者可以擁有個人工作區並加入公司的工作區。
我有多個應用程式
使用 Logto，你可以在單一租戶中管理多個應用程式，無論
- 應用程式的類型（例如，網頁、行動裝置、桌面等）
- 應用程式的使用案例和功能（例如，司機應用程式、叫車應用程式等）
我有多個企業客戶
你可以使用組織和企業級單一登入 (Enterprise SSO) 在單一租戶中管理多個企業客戶。通過配置企業 SSO 電子郵件域設定並使用即時佈建 (Just-in-Time provisioning) 功能，你可以自動化使用企業 SSO 帳戶的使用者加入或登入適當組織的過程。