外包驗證的危機：Val Town 遷移至 Better Auth 的教訓

驗證常被視為商品化的問題——一個已解決的難題，可以交給第三方供應商以加速開發。然而，正如 Val Town 從 Supabase 轉至 Clerk 再到 Better Auth 的過程所示，將身分層外包會帶來難以逆轉的系統性風險。

對許多新創公司而言，「零設定」驗證的誘惑相當強大。但當應用需求演變——尤其是社交平台需要頻繁存取與展示使用者資料時，受管理服務提供的抽象層往往會成為瓶頸。以下是 Val Town 為何拋棄 Clerk，以及在此過程中學到的架構教訓的詳細說明。

「受管理使用者表」的危險

現代驗證服務中最具爭議的架構模式之一，就是建議拋棄自有的 users 表，讓供應商成為唯一的真實來源。雖然這樣可以簡化初始設定，卻會產生兩個主要的失敗點：可靠性與速率限制。

速率限制的陷阱

當服務管理你的使用者表時，所有取得使用者中繼資料（頭像、電子郵件、設定）的請求都必須透過其 API。Val Town 發現，雖然在開發環境中這樣運作順暢，實際上線後情況卻大不相同。

「在正式環境中，該端點的速率限制是每秒五個請求。這是針對整個帳號、所有使用者的限制。」

對於常常需要同時列出多位使用者內容的社交網站而言，這種模型根本行不通。為了繞過限制，開發者往往被迫透過 webhook 將資料同步回自己的資料庫，結果產生兩套真實來源，使用者管理的複雜度也翻倍。

Session 管理成單點故障

當供應商負責 session 時，他們不僅處理登入流程，還成為每一次需要驗證的請求的關鍵路徑。若供應商發生宕機，使用者無法刷新 session cookie，整個網站即使對已登入的使用者也會變得無法使用。

Val Town 注意到，網站的可靠性變成所有關鍵部件可靠性的乘積。正如社群成員在討論中指出的，如果你的軟體、驗證層與雲端供應商各自的可用率都是 99%，則整體可用率會下降到 97%。

評估替代方案

尋找受管理服務的替代品相當困難，因為市場往往被「古老且半被拋棄」的開源函式庫與高風險的供應商鎖定平台所分割。

為什麼選擇 Better Auth？

Better Auth 被選中的原因是它兼具函式庫的便利性與自行託管的主權。與完全受管理的服務不同，它允許開發者自行掌控資料庫與 session 管理，同時提供必要的框架整合（Remix、Fastify、Express）。

主要優勢包括：

  • 降低供應商風險：系統不再依賴第三方持續上線才能讓 session 正常運作。
  • 可擴充性：作為開源函式庫，它比封閉的 API 更「可駭」
  • 無狀態基礎設施：Better Auth 的付費附加功能大多是無狀態的，且不介入 session 管理路徑。

「自行實作」的爭論

此遷移引發了工程師之間更廣泛的討論，圍繞著古老的座右銘：「千萬不要自行實作驗證」。

過去的共識是絕對的，但許多有經驗的開發者現在認為，對於基本需求——bcrypt 密碼、魔法連結與 Postgres 中的 session 表——自行打造簡易內部系統的風險，反而低於依賴複雜且難以看透的第三方服務。正如一位貢獻者所說，受管理服務的「快樂路徑」在你遵循它時相當不錯，但一旦偏離，供應商內部抽象的複雜度就會成為阻礙。

零停機遷移的執行步驟

更換驗證供應商是團隊能執行的最高風險操作之一。Val Town 採用了過渡期以確保平順交接：

  1. 平行支援：兩週內，所有驗證端點同時接受來自 Clerk 與 Better Auth 的 cookie。
  2. 逐步遷移：使用者在登入時即被遷移，登入頁面會發出 Better Auth 的 session。
  3. 手寫最終實作：雖然 LLM 協助產生了過渡程式碼的初始樣板，最終的安全關鍵實作仍由人工手寫並嚴格測試，以避免漏洞。

結語

從 Supabase 到 Clerk 再到 Better Auth 的旅程提醒我們，複雜系統的可靠性是由最薄弱的環節決定的。受管理服務非常適合簡單、前端為主且不含社交功能的應用，但對於需要高可用性與深度使用者資料整合的平台而言，卻可能成為負擔。最令人愉悅的工程往往是「無聊」的領域：擁有自己的資料、掌控自己的 session，並盡可能減少請求路徑中關鍵第三方依賴的數量。

Sources