Better Auth 加入 Vercel

我很高兴地宣布，Better Auth 将加入 Vercel。

从一开始，这支团队就是我们最大的灵感来源，并且一直体现着我们开始投入 Better Auth 的许多原因。

Vercel 与我们一样，致力于让认证保持开源、与框架和平台无关。携手合作让我们拥有更多资源和空间，专注于构建这个社区中许多人所依赖的框架。

我们还将能够更深入地投入到认证的未来方向：一个由代理代表用户行事、并需要安全、受限且可撤销访问权限的未来，同时将这些基础能力带入 Vercel 的产品中。

我非常感激我们的社区，感谢每一位以不同方式激励我们并帮助我们走到今天的人。

Better Auth 是如何开始的

三年前，我正在构建一个开源的 Web 分析平台，我需要加入认证功能。那时候，每当我用 Next.js 开始一个项目时，我都会选择 NextAuth。大多数情况下，我只需要“使用 Google 登录”和一个简单的用户对象，所以它用起来非常不错。

但在那个项目里，我需要组织功能（多租户）：邀请队友、角色、权限，以及完善的访问控制。我寻找过可以直接引入并与 NextAuth 一起使用的方案，但实际上并没有什么现成可用的东西。可选方案要么是自己从头构建，要么是使用第三方认证服务。

我花了几个星期把组织功能做进项目里，并围绕它重构了所有内容，但我仍然对结果不满意。不久之后，我开始尝试 next-org，一个基于 NextAuth 的封装，它会添加组织支持并记录最佳实践。我不断遇到阻碍，API 总是让人觉得不够顺手，最后我还是半途而废了。

然后，我在各处都不断遇到同样的问题。

我当时在做一个小型的 Expo 应用，想加上 OAuth，结果发现用 NextAuth 几乎不可能。后来，我又想看看能不能把一个 Next.js 项目迁移到 Svelte，但根本没有“适用于 Svelte 的 NextAuth”，所以迁移过程非常痛苦。

大约在那段时间里，在 AI 还没有成为日常话题、React 和其他框架之争每隔一周就会爆发一次的时期，X 上经常会有一个反复出现的争论：我们到底应该自己实现认证，还是直接使用服务？

大多数人似乎都想要掌控自己的认证系统。几乎所有“不自己做”的理由，最终都归结为“我不想花时间去实现功能 X”。于是我开始思考，要构建一个与框架无关的认证框架：核心足够简单，适合日常应用；并且可以通过插件扩展出你所需要的任何认证功能。

我想出了 better-auth 这个名字，并给自己立下一个约定：如果这个包名在 npm 上可用，那就是我开始做它的信号。

幸运的是，它是可用的。

于是我开始断断续续地投入其中，前后大约 7 个月，同时还在开发一些相关库，比如 better-fetch（Better Auth 客户端需要它）和 better-call（Better Auth 后端使用的一个简单 Web 服务器框架）。在把整个框架重写了大约四次、为文档等等事情忙得焦头烂额之后，我在 X 上发了一张截图，只有一句：“9 月 28 日。”

那时我几乎没什么关注者，但不知怎么地，那条帖子引起了大家的注意。我花了一周时间完成最后的部分，并在 9 月 28 日发布了第一个版本。

从第一周开始，人们就开始加入 Discord、提交 issue、提供反馈，并且真正开始使用它。Better Auth 在最初三个月一直处于 beta 阶段，而从 2024 年 11 月底之前的每个周五，我都会发布一个包含修复、改进和新功能的新版本，直到我们达到 1.0。

差不多在那个时候，我对这一切变得相当投入。我想持续改进这个框架，积极参与 Discord 社区交流，保持 GitHub 整洁，并通过功能请求和 bug 报告，学习人们提出的每一个新的认证概念。

我觉得这做得非常成功。人们喜爱 Better Auth 的程度，至今仍然让人觉得少见。我不断在 X 上看到赞扬其 DX、API 设计和文档的帖子——开发者社区也开始制作 YouTube 教程、撰写博客文章，并把这个项目推荐给其他人。

Better Auth 成为了一家公司

我以前几乎痴迷地看 Y Combinator 的视频。在那之前，我尝试创办过一家本地创业公司，但我想等到自己真的做出一些运转良好的东西之后，再去申请 YC。

Better Auth 就感觉像那样的东西。

当时还不完全清楚它要如何变成一门生意，但我觉得我们总能把这件事摸索清楚；而如果有人会愿意在我身上下一个赌注，那大概会是 YC。我提交了申请，和 Pete 进行了面试，他很慷慨地给了我一次机会。我被录取了。

对于一个在埃塞俄比亚出生并长大的人来说，进入 YC 是一个非凡的时刻。搬到旧金山参加 YC 让我感觉很不真实。我之前在 X 上长期沉迷于线上世界，以至于我很快就适应了——旧金山基本上就是 X，只不过是现实版。

在 YC 结束时，我们在 Peak XV（前身为 Sequoia India & Southeast Asia）的领投下完成了融资，同时还有 50 多家基金和天使投资人参与，围绕 Better Auth 打造一家公司。也就是从那时起，我开始把思考从开源之外延伸开来：我们会如何招聘，我们会选择线下办公还是远程办公，我们想打造什么样的公司，以及 Better Auth 最终能变成什么。

我们收购了 Auth.js / NextAuth.js

后来，在和 Balázs 聊 Auth.js 的未来计划时，他提到我们在 Better Auth 上所做的很多事情，与 Auth.js 团队一直在考虑的整体方向非常相似。

我们看到了一个机会，让 Better Auth 接手这个项目，并在长期内设法找到一条路径，逐步把大家迁移过来，同时继续维护 Auth.js，并修复安全问题和其他 bug。

这就是 Auth.js / NextAuth.js 最终加入 Better Auth 的经过：

对我来说，这是一个非常圆满的时刻，因为我一开始就是自己在使用 NextAuth。而且我们还得到了像 auth 这个 npm 包这样的酷东西。:)

Better Auth 的下一阶段

当你做开源时，最显而易见的路径就是围绕它构建一个托管平台。但 Better Auth 是一个框架，而人们使用它的一个主要原因，正是他们一开始就不想把认证外包出去。我一直对构建传统的托管认证服务没那么感兴趣。

所以我们的第一个计划——“act one”——是寻找我们可以通过一个扩展框架的平台提供的额外价值：仪表盘、安全功能、审计日志。我们在 1 月 1 日以 Better Auth Infrastructure 的名义发布了第一次尝试。

随后，AI 变化的速度带来了一个无法忽视的新问题：agent 和认证。

一个 agent 代表用户执行操作的世界，会带来一整套全新的安全和授权问题。保障 agentic 工作流的安全，正迅速成为软件领域最重要的挑战之一。

我们开始研究在那样的世界里认证应该是什么样子，推出了 Agent Auth 协议，并开始与其他公司讨论下一个版本——包括 Vercel。

通过这项工作，我们很清楚地意识到，Vercel 是继续推进我们的开源认证使命以及这一新探索的最佳地点。我们是一个小团队；agent 身份问题规模庞大，而且发展迅速。借助 Vercel 的基础设施、分发能力、社区和产品覆盖面，我们可以将这些想法以比我们单独行动大得多的规模带给开发者——而且不会让我们的注意力在维护框架和构建其周边的一切之间分散开来。

接下来会发生什么

Better Auth： 这次转变让我们能够重新聚焦 Better Auth 的最初使命，而不必围绕变现来制定策略——帮助开发者掌控自己的认证。现在，我们还能借助更多资源来增强和扩展 Better Auth 框架。

Agent Auth： 通过我们的 Agent Auth Protocol，我们一直在探索塑造 agent 安全栈的关键基础原语。Vercel 早已站在 agentic 基础设施的前沿，尤其是最近推出的 Eve 和 Vercel Connect，以及一些更高层级的工具，它们让内部应用的认证更容易实现，比如 Vercel Passport。

我们希望在加速迈向 agentic 世界的过程中，推动基础设施的身份与访问层演进。

最后说明

感谢过去几年里所有曾经参与这个团队的每一个人，也感谢社区中的每一位，以及我们的客户，是你们以如此多的方式推动了这个项目向前发展。

感谢开源维护者和构建者们，这个项目所依赖的正是你们的工作，我也从中学到了很多。

感谢 Pete Koomen、Peak XV 的 Arnav Sahu，以及每一位在我早期就给予支持、一路陪伴并支持我走到今天的投资人。

感谢 Vercel 的每一位成员促成了这一切，我很期待一起继续建设！