全面指南：設置多租戶認證與授權
建立一個多租戶應用程式可能會很複雜。這篇文章聚集了我們所有關於多租戶和組織策略的過去帖子，希望能幫助你節省時間並輕鬆開始。
Product & Design
建立多租戶應用程式可能具有挑戰性，涉及考量很多方面。這篇文章彙整了我們之前對理解多租戶和組織實踐的部落格文章。為了快速開始並節省時間，只需查看這篇文章，它包含你所需的一切！
一般指南概要如下步驟：
- 理解多租戶架構
- 繪製你的多租戶應用程式使用案例
- 實現租戶隔離
- 定義你想如何管理身份
- 選擇合適的授權模型
什麼是多租戶架構
軟體多租戶是一種軟體架構，其中一個實例的軟體在服務器上運行並為多個租戶提供服務。這種設計的系統是“共享的”（而不是“專用的”或“隔離的”）。
租戶是一組在軟體實例中共享共同訪問並具有特定權限的用戶群體。
多租戶設計的關鍵心態之一是“共享”。在更廣泛的多租戶定義中，成為一個多租戶應用程式並不意味著解決方案中的每個組件都是共享的。相反，它意味著解決方案中的至少某些組件在多個租戶之間被重用。全面理解這個術語更能幫助你同理客戶的需求及其來源。
一旦理解了多租戶架構，接下來的步驟就是將你的應用程序應用到實際場景中，重點關注特定的產品和商業需求。
多租戶應用程式的用例是什麼？
SaaS中的多租戶
多租戶應用程序通常在企業對企業（B2B）解決方案中找到其定位，如生產力工具、協作軟體和其他軟體即服務（SaaS）產品。在此上下文中，每個“租戶”通常代表一個商業客戶，它可能有多個用戶（其員工）。此外，一個商業客戶可能有多個租戶以代表不同的組織或商業部門。
常見B2B用例中的多租戶
B2B應用程序不僅限於SaaS產品，並且通常涉及使用多租戶應用程序。在B2B環境中，這些應用程序用作各種團隊、商業客戶和合作夥伴公司訪問你應用程序的公共平台。
例如，考慮一個提供B2C和B2B應用程序的共乘公司。B2B應用程序為多個商業客戶服務，採用多租戶架構可幫助管理其員工和資源。為了說明，假如公司希望維持統一的用戶身份系統，可以設計如下示例的架構：
Sarah同時擁有個人和商務身份。她作為乘客使用共乘服務，並在業餘時間擔任司機。在她的專業角色中，她還管理她的業務，並利用此商務身份作為Business 1的合作夥伴。
為什麼應該在SaaS產品中使用多租戶
使用多租戶進行擴展
對於企業業務，多租戶是有效滿足他們可用性、資源管理、成本管理和數據安全需求的關鍵。在技術層面，採取多租戶方法可以簡化你的開發過程，減少技術挑戰，並促進無縫擴展。
創建統一的體驗
在考察SaaS產品的根源時，就像一棟有多個公寓的建築。所有租戶共享水、電和天然氣等公共設施，但他們對自己的空間和資源擁有獨立的管理權限。這種方式簡化了物業管理。
通過租戶隔離確保安全
在多租戶架構中，引入“租戶”這個術語來創建界限，將不同租戶的資源和數據分隔並保護在共享實例中。這確保每個租戶的數據和操作保持獨立和安全，即使它們正在使用相同的底層資源。
為什麼你應該實現租戶隔離？
在討論多租戶應用程式時，總是有必要實現租戶隔離。這意味著在共享系統中將不同租戶的數據和資源分開並保持安全（例如，雲基礎設施或多租戶應用程式）。這可以防止任何未經授權的嘗試進入其他租戶的資源。
雖然解釋可能看起來抽象，我們將使用實例和關鍵細節進一步說明隔離心態和實現租戶隔離的最佳實踐。
租戶隔離不違反多租戶“共享”心態
那是因為租戶隔離不一定是一個基於基礎設施資源的結構。在多租戶和隔離的領域，一些人將隔離看作是實際基礎設施資源之間的嚴格劃分。這通常導致了每個租戶擁有單獨的數據庫、計算實例、賬戶或私有雲的模型。在共享資源場景中，如多租戶應用程式，實現隔離的方法可以是邏輯結構。
租戶隔離專注於使用“租戶”上下文來限制對資源的訪問。它評估當前租戶的上下文並使用該上下文來確定哪些資源對於該租戶是可訪問的。
認證和授權不等於“隔離”
使用認證和授權來控制對SaaS環境的訪問是重要的，但這對於完整隔離是不夠的。這些機制只是安全拼圖中的一部分。
人們常常會問一個問題，我能使用通用授權解決方案和角色基於訪問控制來實現租戶隔離嗎？
事實是，你可以構建一個多租戶應用程式，但你不能說你已經實現並採用了租戶隔離策略作為最佳實踐。我們通常不推薦這樣做，因為
為了說明，考慮一種情況，你已經 為你的SaaS系統設置了認證和授權。當用戶登錄時，他們會收到包含有關其角色的信息的令牌，指示他們在應用程式中可以做什麼。這種方法增強了安全性，但不能確保隔離。
使用“組織”來表示SaaS產品租戶，以實現租戶隔離
僅靠認證和授權不足以防止擁有正確角色的用戶進入其他租戶的資源。因此，我們需要引入“租戶”上下文，如租戶ID，以限制對資源的訪問。
這就是租戶隔離發揮作用的地方。它使用租戶特定標識符設置界限，像牆壁、門和鎖一樣，確保租戶之間的明確分隔。
多租戶應用程式中的身份管理
我們談到了租戶隔離，那麼身份呢？你怎麼決定你的身份是否應該“隔離”？
在“身分隔離”概念周圍經常存在混淆。這可能指的是一個真實世界的用戶在一般理解中有兩個身份的情況。
- 兩個身分可以存在於統一的身分系統中。例如，Sarah可能有一個與統一登錄（SSO）相連的個人郵件和公司郵件。
- 用戶在完全不同的身份系統內維持兩個不同的身份，代表完全無關的產品。
有時，這些場景被稱為“身份隔離”。然而，這個標籤可能無助於做出決定。
而不是確定你是否需要“身份隔離”，考慮
這個答案可以指導你的系統設計。關於多租戶應用程式的簡要回答，
在多租戶應用程式中，身份與租戶特定的資源和數據不同，是在多個租戶之間共享的。想像一下你是建築管理員，你不想維持兩個獨立的名單來管理你的租戶的身份。
當目標是租戶隔離時，你可能已經注意到了對“組織”這個術語的反復強調，這通常被認為是為多租戶應用程式構建的最佳實踐。
通過採用“組織”的概念，你可以在你的多租戶應用程式中實現租戶隔離，同時維持一個統一的身份系統。
如何選擇和設計合適的授權模型
在選擇適當的授權模型時，考慮以下問題：
- 你是開發B2C、B2B還是兩者結合 ？
- 你的應用程序是否有多租戶架構？
- 根據業務單位，應用程式中是否需要某一級別的隔離？
- 在組織的上下文中需要定義哪些權限和角色，而哪些不需要？
在Logto中有哪些不同的授權模型？
基於角色的訪問控制
RBAC（基於角色的訪問控制）是一種基於用戶角色授予權限的方法，可以有效地管理資源訪問。
這種常見技術是訪問控制的基礎，也是Logto授權功能的關鍵組成部分。作為一個全面的身份管理平台，Logto為各種層次和實體提供量身定制的解決方案，滿足開發人員和企業的多樣產品架構。
API基於角色的訪問控制
為保護不特定於任何組織且不需要上下文限制的常規API資源，API RBAC 功能是理想的。
只需註冊API並為每個資源分配權限。然後通過角色與用戶的關係控制訪問。
這裡的API資源、角色和權限在統一身份系統下是“民主化”的，這在層次較少且不需要非常深層隔離的B2C產品中很常見。
組織基於角色的訪問控制
在B2B和多租戶環境中，租戶隔離是必要的。為了實現這一點，組織被用作隔離的上下文，這意味著RBAC只有在用戶屬於特定組織時才有效。
組織RBAC著重於在組織層面而不是API層面控制訪問。這對於長期來說在組織級別自我管理中提供了高度靈活性，但仍在統一身份系統中。
一個關鍵的組織RBAC特性是角色和權限通常在所有組織中默認相同，使得Logto“組織模板”在提高開發效率方面極具意義。這符合多租戶應用程式的共享理念，即訪問控制策略和身份是所有租戶（應用程式租戶）之間的共同基礎設施組件，這是SaaS產品中的常見做法。
結語
這篇文章提供了一切你所需的，以準備和配置多租戶應用程式。今天就試試Logto，開始運用組織的多租戶應用程式開發最佳實踐。