外包身份验证的风险：Val Town 迁移到 Better Auth 的教训

身份验证常被视为一种商品——一个已解决的问题，可以交给第三方提供商以加速开发。然而，正如 Val Town 从 Supabase 迁移到 Clerk 再到 Better Auth 的过程所示，将身份层外包的决定可能会引入难以逆转的系统性风险。

对于许多初创公司来说，“零配置”身份验证的诱惑非常大。但当应用的需求演变——尤其是对用户数据频繁访问和展示的社交平台——托管服务提供的抽象层可能会成为瓶颈。下面详细阐述 Val Town 为什么放弃 Clerk，以及在迁移过程中得到的架构教训。

“托管用户表”的危险

现代身份服务中最具争议的架构模式之一是建议删除自有的 users 表，让提供商成为唯一的真相来源。虽然这简化了初始设置，却会产生两个主要的故障点：可靠性和速率限制。

速率限制的陷阱

当服务管理你的用户表时，所有用户元数据（头像、邮箱、设置）的请求都必须通过它们的 API。Val Town 发现，这在开发环境中运行顺畅，但在生产环境中情况截然不同。

"在生产环境中，该端点的速率限制是每秒五次请求。针对整个账户的所有用户。"

对于一个社交网站来说，页面经常列出多个用户的内容，这种模型根本行不通。为规避此问题，开发者往往被迫通过 webhook 将数据同步回自己的数据库，实际上产生了两个真相来源，用户管理的复杂度翻倍。

会话管理的单点故障

当提供商管理会话时，它们不仅处理登录，还成为每一次需要身份验证的请求的关键路径。如果提供商出现故障，用户无法刷新会话 cookie，整个站点即使对已登录用户也不可用。

Val Town 指出，站点的可靠性等同于其所有关键部件可靠性的乘积。正如社区成员在讨论中指出的，如果你的软件、身份层和云提供商各自的可用性为 99%，则整体可用性会降至 97%。

评估替代方案

寻找托管服务的替代品并不容易，因为市场往往被“古老且半被抛弃”的开源库和高风险的供应商锁定平台所分割。

为什么选择 Better Auth？

Better Auth 被选中的原因是它在库的便利性与自托管的主权之间取得了平衡。与完全托管的服务不同，它允许开发者保持对数据库和会话管理的控制，同时提供必要的框架集成（Remix、Fastify、Express）。

主要优势包括：

降低供应商风险：系统不再依赖第三方在线来维持会话功能。
可扩展性：作为开源库，它比封闭的 API 更“可 hack”。
无状态基础设施：Better Auth 的付费插件大多是无状态的，不参与会话管理路径。

“自行实现”争论

此次迁移在工程师中引发了更广泛的讨论，围绕古老的格言：“绝不要自行实现身份验证”。

过去的共识是绝对的，但如今许多有经验的开发者认为，对于基本需求——bcrypt 密码、魔法链接以及 Postgres 中的会话表——构建一个简单的内部系统的风险低于依赖复杂且不透明的第三方服务。正如一位贡献者所说，托管服务的“幸福路径”在你偏离它时就会显现，其内部抽象的复杂性会成为阻碍。

零停机迁移的执行

更换身份验证提供商是团队可以执行的最高风险操作之一。Val Town 使用了过渡期来确保平稳交接：

并行支持：两周内，所有身份验证端点同时接受 Clerk 和 Better Auth 的 cookie。
逐步迁移：用户在登录时被迁移，登录页面发放 Better Auth 会话。
手写终结：虽然 LLM 在编写过渡代码的初始模板时提供了帮助，但最终的安全关键实现全部手写并经过严格测试，以避免漏洞。

最后思考

从 Supabase 到 Clerk 再到 Better Auth 的旅程提醒我们，复杂系统的可靠性取决于最薄弱的环节。托管服务非常适合简单、前端为主且没有社交组件的应用，但对于需要高可用性和深度用户数据集成的平台，它们可能成为负担。最令人愉悦的工程往往是“乏味”的领域：拥有自己的数据，控制自己的会话，尽量减少请求路径中关键第三方依赖的数量。