Logto 的多租戶模型解析

混淆#

你可能聽說過一些產品使用「多租戶」這個詞來表示身份隔離：每個租戶都有自己的一套用戶、角色、權限和數據。

這可能有些反直覺，但事實上，「多租戶」表示相反：多個租戶共享單個實例中的資源。對用戶來說，應用程式中的身份就像是駕照。例如，有了駕照，你可以在不同州駕駛（多個組織的一個身份），而不是為每個州重新申請新的駕照。

Logto 的模型#

在 Logto，我們注意到了設計之初的這個混淆，並努力為你的應用程式和用戶搞清楚這一點。以下是我們的設計：

• 一個租戶可以被視為一個 Logto 實例，它擁有自己的一套用戶、權限和數據。
• 在一個租戶內，可能有多個組織。一個用戶可以是多個組織的成員。
• 對於每個組織，它遵循基於角色的訪問控制模式（RBAC），並使用相同的組織角色和組織權限集合。這個集合被稱為組織模板。
• 組織角色和組織權限只有在組織的上下文中才有效。
  • 例如，某個用戶可以在一個組織中是「管理員」（角色），在另一個組織中是「成員」（角色）。
  • 沒有組織的上下文，組織角色和組織權限是無意義的。
• 使用組織權限來控制組織中的訪問，而不是使用組織角色。

這個模型提供了管理身份的靈活性和可重用性，特別是對於 SaaS 應用程式。如果我們看看一些熱門的 SaaS 應用程式，可以發現它們都可以適應這個模型。在不同的應用程式中，「組織」的術語可能會不同，例如「工作區」、「團隊」等。但概念是一樣的。

例如，在 Notion（一個流行的協作工具）中：

• 你可以用一個帳戶創建和加入多個工作區，而不是為每個工作區註冊不同的帳戶。
• 對於每個工作區，Notion 定義了一個相同的訪問層級：「工作區擁有者」、「成員」，而你可能期望不同的工作區有不同的訪問層級。

因此，用戶可以輕鬆在工作區之間切換，而不需要切換帳號或重新登入，並且保持工作區之間的隔離。將此轉換為 Logto 的模型，這意味著：

• 組織模板定義了兩個角色：「擁有者」和「成員」。
• 如果用戶加入了一個工作區，這意味著該用戶是一個組織的成員，並在該組織中有「成員」角色。
• 如果用戶創建了一個工作區，這意味著該用戶是一個組織的成員，並在該組織中有「擁有者」角色。

根據不同角色，用戶可以在不同的工作區（組織）中擁有不同的權限。

優勢#

使用者體驗#

對於用戶而言，他們可以享受真正的單次登入體驗。在組織間切換就像在標籤間切換一樣簡單。

可重用性#

SaaS 應用程式的一個優勢是它們是標準化的且可擴展的。例如，你可以在 Notion 中點幾下就創建一個新工作區，並且可以立即使用。

當你的應用程式成長時，你可能想要為每個組織新增更多角色和權限。例如，一個新角色「訪客」和一個新權限「invite:guest」。如果你需要逐一更新所有現有的組織，這可能是一場噩夢。

使用 Logto，你可以更新組織模板，然後所有現有的組織將會自動更新。

一個訪問控制模型，多個使用情境#

在 Logto，我們使用相同的訪問控制模型（RBAC）來管理組織和 API 資源。這意味著，如果你對 RBAC 熟悉，就不需要學習新的訪問控制模型。同時，它們是彼此隔離的，因此你可以將它們用於不同的使用情境。

最激動人心的部分是，你能同時使用它們。讓我們擴展 Notion 的例子：

• 對於訪問工作區，你可以使用 Logto 組織 RBAC。
• 對於訪問和更新帳戶級別的資源（如個人資料和帳單信息），你可以使用 Logto API 資源 RBAC。

大多數的 Logto SDK 支援這兩種類型的 RBAC。

不同點

組織 RBAC 和 API 資源 RBAC 在以下方面有所不同：

• 組織 RBAC 需要組織的上下文，而 API 資源 RBAC 則不需要。
• 組織 RBAC 用於控制組織內的訪問，而 API 資源 RBAC 用於控制對 API 資源的訪問。
• 用戶可以在不同的組織中擁有不同的組織角色，而 API 資源的角色在租戶中是通用的。
• 這兩種類型的 RBAC 角色和權限是彼此隔離的。

結語#

建立一個 SaaS 應用程式是很困難的，我們希望 Logto 可以幫助你專注於核心業務。如果你有任何疑問或建議，請不要猶豫給我們反饋。