輕量 SDK,獨立服務
Logto 作為獨立的身份驗證服務運行,與你的產品完全解耦。它的 SDK 是輕薄、基於標準的 OAuth 2.1/OIDC 客戶端,只負責把你的應用連接到該服務。沒有任何東西會在你的應用打包產物中嵌入 UI 和會話運行時,因此你可以獲得現代身份驗證,而無需犧牲前端效能。
Clerk 以出色的開發者體驗聞名,尤其是在 Next.js 生態系統中 。但隨著應用規模擴大、架構要求日趨複雜,團隊往往發現緊密耦合、偏重前端的方案會成為負累。
| 動機 | 實際情況 |
|---|---|
| SDK 臃腫與效能問題 | Clerk 的預構建 React 組件很方便,但它們會在你的打包產物中嵌入沉重的 UI 和會話運行時。這個代價有公開記錄:2023 年 Clerk GitHub 上的一個 issue 測得完整的 clerk-js 套件達 1.2 MB,而 Clerk 自己的比較文章也承認,使用預構建組件時,其主包「可佔應用總體積多達 50%」。 |
| 僵化的會話架構 | Clerk 充當用戶會話的唯一事實來源。當你構建需要自訂租戶路由或機器對機器通信的複雜 B2B 應用時,繞開這種以用戶為中心的架構會令人非常沮喪。 |
| 沒有自託管選項 | Clerk 是專有、僅限雲端的 SaaS。如果你交付的軟件需要在企業客戶的本地環境運行,或者你需要完全掌控自己的基礎設施,Clerk 根本不在選項之列。 |
| 偏離標準協議 | 與企業系統整合的開發者,會遇到 Clerk 實現標準協議時的種種特異之處,例如缺少標準的 OIDC 登出端點。 |
| 多應用登入猶如事後補救 | 在你自己的多個應用之間共享同一個登入,正是 Clerk 顯得吃力的地方。Satellite domains 只涵蓋同一個 Clerk 應用下的 Web 應用,且僅支援少數框架,登入仍然要在主域名上進行。獨立的 Clerk 應用之間無法共享用戶或會話,而原生應用更是完全沒有文檔記載的做法。 |
Logto 作為獨立的身份驗證服務運行,與你的產品完全解耦。它的 SDK 是輕薄、基於標準的 OAuth 2.1/OIDC 客戶端,只負責把你的應用連接到該服務。沒有任何東西會在你的應用打包產物中嵌入 UI 和會話運行時,因此你可以獲得現代身份驗證,而無需犧牲前端效能。
大多數團隊使用 Logto Cloud,從不需要操心基礎設施。但如果你銷售的軟件要由企業客戶在本地部署,你就不能硬性依賴第三方身份驗證雲服務。Logto 的開源核心以單一輕量伺服器運行,可以打包進你的產品之內。
Logto 嚴格遵循 OAuth 2.1、OIDC 和 SAML。標準的發現文檔、標準的登出端點、標準的斷言。Logto 的行為與規範所述一致,因此與企業系統的整合始終順暢。
我們相信誠實的定位。Logto 並非適合每一位 Clerk 客戶的完美選擇。