Logto 的多租戶模式解釋

混亂#

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

可能不合常理，但事實上，「多租戶」表示相反的意思：多個租戶在一個實例中共享資源。對用戶來說，應用程式中的身份就像駕駛執照。例如，一張駕駛執照可以在不同的州駕駛（多個組織使用一個身份），而不是為每個州重新申請駕駛執照。

Logto 的模型#

在設計初期，我們注意到這種混亂，並努力為你的應用程式和用戶改正過來。這是我們的設計：

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

這種模式為管理身份提供了靈活性和重用性，尤其對於 SaaS 應用程式而言。如果我們看看一些流行的 SaaS 應用程式，我們可以發現它們都可以適應這種模式。不同應用程式中「組織」這個詞可能不同，比如「工作區」、「團隊」等。但概念是相同的。

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

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

因此，用戶可以輕鬆在不同的工作區間切換，而不需切換賬戶或重新登錄，並且保持工作區間的隔離。轉化成 Logto 的模型，這意味著：

• 組織模版 定義了兩個角色：「擁有者」和「成員」。
• 如果用戶加入了工作區，這表示用戶是 組織 的成員，他們在 組織 中擁有「成員」角色。
• 如果用戶創建了工作區，這表示用戶是 組織 的成員，他們在 組織 中擁有「擁有者」角色。

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

益處#

用戶體驗#

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

重用性#

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

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

使用 Logto，你可以更新組織模版，所有現有組織都會自動更新。

一個訪問控制模型，多個用例#

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

最令人興奮的部分是你可以同時使用它們。讓我們延伸一下 Notion 的例子：

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

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

差異

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

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

結語#

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