Tesseral 是一個面向 B2B 軟體的新開源認證服務，它採用了獨特的使用者和組織處理方式。然而，它的設計選擇在開發者社群中引發了關於商業應用中處理多租戶最佳方式的重要討論。
** Tesseral 主要功能：**
- 多租戶 B2B SaaS 身份驗證
- SAML SSO 和 SCIM 配置
- 基於角色的訪問控制（ RBAC ）
- 多因素身份驗證（ MFA ）
- 魔術連結和社交登入
- 用於除錯的使用者模擬功能
- API 金鑰管理
- 自託管或託管服務選項
爭議性的設計決策
Tesseral 的架構要求每個使用者只能屬於一個組織，這意味著一個人需要多個使用者賬戶才能訪問不同的工作空間。這種方法與許多開發者的期望不同——他們期望一個使用者可以同時屬於多個組織。社群反應不一，多名開發者對這一限制表示擔憂。
一名開發者指出了這種模型的主要可用性問題，提到像 Datadog 這樣的服務使用類似方法，使用者必須在組織之間完全切換上下文。這會阻止使用者並排開啟來自不同組織的標籤頁，並導致使用者在錯誤的組織上下文中時連結失效。
使用者-組織模型對比：
| 服務 | 使用者模型 | 多組織訪問 |
|---|---|---|
| Tesseral | 每個組織一個使用者 | 需要多個賬戶 |
| FusionAuth | 全域性使用者與租戶註冊 | 單一使用者，多個租戶 |
| 傳統模式 | 多對多關係 | 單一使用者，多個成員身份 |
討論的替代方案
討論揭示了其他認證服務處理這一挑戰的各種方式。一些開發者建議使用傳統術語如使用者、成員關係和賬戶來建立多對多關係。其他人提到 FusionAuth 使用全域性使用者概念配合租戶特定註冊，允許同一個人透過全域性和應用特定的使用者 ID 進行引用。
幾名社群成員倡導更簡單的模型，讓使用者無需建立單獨賬戶即可訪問多個組織。他們認為這種方法減少了混亂並提供更好的使用者體驗，特別是對於員工可能需要訪問多個部門或子公司的大型組織。
更廣泛的認證服務格局
Tesseral 的推出為日益擁擠的認證服務領域增加了新成員。討論中的開發者將其與 Auth0、Clerk、Keycloak 等成熟廠商以及 Stack Auth 等新進入者進行了比較。每個服務都採用不同的方法來解決認證挑戰，有些專注於特定框架或部署模型。
有趣的是，討論還揭示了對雲依賴日益增長的擔憂，特別是在歐洲公司中。幾名開發者提到，由於資料主權和地緣政治考慮，對 AWS 和其他美國雲提供商的依賴正成為歐洲企業的重要考量。
可用的 SDK：
- 客戶端： React
- 服務端： Express、Flask、Golang
- 開發中： Django、Laravel、Rails、Fastify
自託管與託管服務的辯論
雖然 Tesseral 提供託管和自託管選項，但社群討論突出了便利性與控制權之間的持續緊張關係。一些開發者更喜歡使用成熟框架如 Rails 配合 Devise 構建自己的認證系統，而其他人則欣賞託管服務為 SAML SSO 和多因素認證等複雜功能提供的時間節省。
這場辯論反映了關於何時構建與購買的更廣泛問題，特別是對於認證等關鍵基礎設施。正如一名開發者所說，認證錯誤可能特別昂貴且難以後期修復，這使得自定義開發與第三方服務之間的選擇變得尤為重要。
結論
Tesseral 的推出突出了關於認證服務應如何處理 B2B 應用中多租戶的基本問題。雖然該服務為商業軟體提供了全面的功能，但其使用者-組織模型引發了關於使用者體驗和架構權衡的重要討論。社群反饋表明，認證服務提供商必須仔細平衡技術實現與使用者期望和現實使用模式。
參考：Tesseral