Better Auth 加入 Vercel

# Better Auth 加入 Vercel 来源：https://better-auth.com/blog/better-auth-joins-vercel 我很激动地宣布，Better Auth 正式加入 Vercel。 从一开始，这个团队就是我们的最大灵感来源，也一直映射着我们启动 Better Auth 项目的很多初衷。 Vercel 与我们一样，致力于保持身份认证框架的开源、框架无关和平台无关。强强联手让我们拥有更多资源和空间，专注于构建整个社区所依赖的框架。 此外，我们也将能够更深入地投入到身份认证的未来走向：一个代理可以代表用户行动、需要安全、细粒度且可撤销访问权限的世界，同时将这些基础能力带到 Vercel 的产品中。 我由衷感谢我们的社区，感谢每一位以不同方式激励我们、帮助我们走到今天的人。 三年前，我正在构建一个开源的网站分析平台，需要添加身份认证功能。那时，每当我用 Next.js 启动一个项目，我都会直接使用 NextAuth。大多数情况下，我只需要“用 Google 登录”和一个简单的用户对象，所以效果很好。 但那个项目需要组织（多租户）：邀请团队成员、角色、权限、适当的访问控制。我寻找了一些可以和 NextAuth 一起使用的现成方案，但几乎没有。要么自己构建，要么使用第三方身份认证服务。 我花了大约两周时间把组织功能集成到项目中，并重构了相关代码，但结果仍不满意。不久后，我开始尝试 `next-org`，这是一个基于 NextAuth 的包装器，用于添加组织支持并记录最佳实践。但我不断遇到障碍，API 始终不够易用，最终半途而废。 后来，我到处都遇到同样的问题。 我在开发一个小的 Expo 应用时，用 NextAuth 添加 OAuth 几乎不可能。后来，我想看看能否把 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 在前三个月一直处于测试阶段，2024 年 11 月底之前的每个星期五，我都会发布一个新版本，包含修复、改进和新功能，直到达到 1.0 版本。 那时，我对这一切变得非常投入。我想不断改进框架，保持与 Discord 社区的互动，保持 GitHub 整洁，并通过功能请求和错误报告学习每一个新的身份认证概念。 我认为效果非常好。人们以罕见的方式喜爱 Better Auth。我不断在 X 上看到赞扬开发者体验、API 设计和文档的推文，开发者社区开始制作 YouTube 教程、撰写博客文章，并向其他人推荐这个项目。 我曾经虔诚地观看 Y Combinator 的视频。我曾尝试在当地创业，但我想只在真正有成果时才申请 YC。 Better Auth 就是那个成果。 虽然还不完全清楚它将如何成为一项业务，但我想我们会解决这个问题，如果有人愿意在我身上赌一把，那个人就是 YC。我申请了，与 Pete 进行了面试，他很慷慨地给了我一个机会。我加入了 YC。 对于一个在埃塞俄比亚出生并长大的人来说，进入 YC 是一个非凡的时刻。搬到旧金山参加 YC 感觉不真实。我花了太多时间在网上刷 X，所以很快就熟悉了——旧金山基本上就是现实版的 X。 YC 结束时，我们完成了由 Peak XV（前身为红杉印度及东南亚）领投、超过 50 家基金和天使投资人参与的融资，围绕 Better Auth 建立公司。那时我开始思考开源之外的事情：如何招聘，是实体办公还是远程办公，想建立什么样的公司，以及 Better Auth 能成为什么。 后来，在与 Balázs 讨论 Auth.js 的未来计划时，他分享道，我们 Better Auth 的很多做法与 Auth.js 团队一直思考的大方向相似。 我们看到了一个机会：让 Better Auth 接管该项目，并长期规划如何引导用户迁移，同时继续维护 Auth.js、修复安全问题和其它漏洞。 这就是 Auth.js / NextAuth.js 最终加入 Better Auth 的原因： 对我来说，这是一个圆满的时刻，因为我最初就是使用 NextAuth 的。我们还获得了 `auth` 这个 npm 包名等很酷的东西。:) 当你构建开源项目时，显而易见的路径是围绕它构建一个托管平台。但 Better Auth 是一个框架，人们使用它的主要原因之一就是他们不想将身份认证外包出去。我从未对构建传统的托管身份认证服务有多大兴趣。 所以我们的第一个计划——“第一幕”——是寻找通过一个扩展框架的平台提供的额外价值：仪表盘、安全功能、审计日志。我们在 1 月 1 日以 Better Auth Infrastructure 的名义发布了首次尝试。 然后，人工智能变革的加速使得一个新问题变得不可忽视：代理与身份认证。 在一个代理代表用户行动的世界里，出现了一系列全新的安全和授权问题。保护代理工作流正迅速成为软件领域最重要的挑战之一。 我们开始研究在那个世界中身份认证应该是什么样子，发布了 Agent Auth 协议，并开始与其他公司讨论下一代版本——包括 Vercel。 通过这项工作，我们清楚地认识到 Vercel 是继续推进我们的开源身份认证使命以及这次新探索的最佳场所。我们团队很小；代理身份认证问题很大且发展迅速。借助 Vercel 的基础设施、分发能力、社区和产品覆盖面，我们可以将这些理念以远超我们单独所能达到的规模带给开发者——而且无需在维护框架和构建周边一切之间分散精力。 ### 接下来会发生什么 (https://better-auth.com/blog/better-auth-joins-vercel#whats-coming-next) **Better Auth：** 这次转型让我们能够重新专注于 Better Auth 的原始使命，而无需围绕盈利来制定战略——帮助开发者掌控自己的身份认证。现在，我们可以用更大的资源通道来增强和扩展 Better Auth 框架。 **Agent Auth：** 通过我们的 Agent Auth Protocol，我们一直在探索塑造代理安全栈的关键基元。Vercel 已经在代理基础设施领域走在前列，尤其是最近推出的 Eve 和 Vercel Connect，以及更高级的工具如 Vercel Passport，使得内部应用的身份认证更加简单。 我们希望随着我们加速进入代理世界，推动基础设施身份和访问层的演进。 感谢过去几年里成为这个团队一员的每一个人，感谢社区中的每一位以及我们的客户，他们以各种方式推动了这个项目。 感谢这个项目所依赖的开源维护者和建设者，我从他们身上学到了很多。 感谢 Pete Koomen、Peak XV 的 Arnav Sahu，以及每一位早期信任我并在整个旅程中支持我的投资人。 感谢 **Vercel** 的每一位让这一切成真的人，期待和大家一起建设！