两年前，你的 Auth0 账单是每月几十美元。今天，那个数字可能已经变成了几百甚至几千。
不是你的用户变多了多少，而是 Okta 收购 Auth0 之后，整个定价体系悄悄重构了一遍。免费层从原来的无限 MAU 压缩到 7500 个月活用户，超出之后按阶梯计费，到了 B2B 功能、Organizations、MFA 这些你迟早要用的特性，又要跳到更高的方案。很多团队在产品还没盈利的时候，每个月就得先交一笔不小的”认证税”。
这不只是钱的问题。更深的问题是：你的用户数据、你的认证逻辑，全部托管在一个你控制不了的第三方平台上。如果 Okta 明天再改一次定价，你的选项只有接受，或者痛苦地迁移。
这种感觉，越来越多的开发者和技术团队都经历过了。
几条不同的路
认证这件事，市场上的解法大致可以分成四类，它们代表了完全不同的设计哲学。
Auth0 走的是”托管一切”的路线。你不需要关心底层，所有功能开箱即用，支持文档详尽，SDK 覆盖几乎所有主流语言。代价是：你的用户数据住在 Okta 的服务器上，定价结构复杂，企业功能分层明显，一旦深度集成，迁出成本极高。这是一种典型的 SaaS 锁定，产品越好用，离开越难。
Firebase Authentication 更像是 Google 生态里的一块砖。如果你的应用已经在用 Firestore、Cloud Functions、Firebase Hosting，那 Firebase Auth 的集成体验确实顺滑。但它的设计从一开始就是为 Google 的生态服务的，用户数据存在 Google 的基础设施里，管理界面简陋，自定义空间有限。对于不想全押 Google 的团队，它更像是一个便捷的绑架工具。邮件和社交登录免费，但一旦你想做手机号验证，超过每月 1 万次就要付费，而且这个上限在用户规模稍大的产品里会很快触达。
AWS Cognito 是三者里最”技术”的一个，前 5 万 MAU 免费，之后约 $0.0055 每个 MAU，算下来比 Auth0 便宜得多。但便宜是有代价的。Cognito 的学习曲线陡峭，User Pool、Identity Pool 两套概念搅在一起，配置选项繁多，UI 难看，SDK 设计反人类。更麻烦的是迁移：Cognito 存密码的方式是自己的，你几乎没有办法把用户数据完整迁走，很多团队选择 Cognito 的时候没想到后来会被它锁死。有开发者在论坛描述过这段经历：当他们决定离开时，才发现所有用户都必须重置密码，没有别的路。
然后是 SuperTokens。
—
SuperTokens 是什么
SuperTokens 是一个开源的认证框架，你可以选择自托管（在自己的服务器上跑），也可以选择他们托管的云服务。自托管版本完全免费，没有 MAU 限制，没有功能分层，代码就在 GitHub 上，MIT 协议。
它支持邮件密码登录、社交登录（Google、GitHub、Apple 等）、无密码（Magic Link、OTP）、Session 管理、MFA，以及 B2B 场景下的 Tenant 隔离。核心功能用 Node.js 写成，SDK 覆盖 Node、Python、Go、Java，前端支持 React、Vue、Angular、以及原生移动端。
自托管的模式意味着：用户数据在你自己的数据库里，你用 PostgreSQL 还是 MySQL 都行，认证服务运行在你自己的机器或容器里，整个技术栈你都可以看到、修改、控制。
这是根本上不同的一种选择。
—
核心功能横向对比
在具体场景下，四个方案的差异会更清晰：
| 功能/维度 | Auth0 | Firebase Auth | AWS Cognito | SuperTokens |
|---|---|---|---|---|
| 免费 MAU 上限 | 7,500 | 无限（邮件/社交） | 50,000 | 无限（自托管） |
| 超出后计费 | 阶梯计费，增长快 | 按功能付费 | ~$0.0055/MAU | $0（自托管） |
| 数据托管位置 | Okta 服务器 | Google 服务器 | AWS 服务器 | 你自己 |
| B2B/多租户 | 付费功能 | 不支持 | 有限支持 | 开源版支持 |
| MFA | 付费功能 | 基础支持 | 支持 | 开源版支持 |
| 迁出难度 | 高 | 中-高 | 极高 | 低 |
| 自定义 UI | 受限 | 受限 | 非常受限 | 完全控制 |
| 开源 | 否 | 否 | 否 | 是（MIT） |
这张表只是起点。真正决定选哪个的，是你对”控制权”这件事的态度。
—
自托管的真实成本
有人看到”自托管”就会想：这不是把运维压力转移到自己身上吗？
这是个合理的顾虑，值得认真算一下。
SuperTokens 的核心服务是一个 Docker 容器，内存占用约 200-300MB，CPU 消耗极低。一个普通的 $10/月 VPS 或者你现有 ECS 集群里一个小型任务就能跑起来。数据库复用你已有的 PostgreSQL 或 MySQL 实例，不需要额外的托管数据库。
所以对于一个已经有服务器的团队，SuperTokens 自托管的边际成本几乎是零，你只是多了一个容器。
当然，你需要自己负责更新、备份、监控。这是真实存在的运维开销。但对比 Auth0 月活超 1 万之后的账单，很多团队算完之后会发现，这笔运维开销换来的掌控感是值得的。
—
从 Auth0 迁过来有多难
SuperTokens 提供了一个专门的迁移工具。核心思路是”懒迁移”：你不需要一次性导出所有用户并重置密码。相反，你配置 SuperTokens 接管登录流程，当用户用原来的密码登录时，SuperTokens 会拿着这个密码去验证 Auth0 的 API，验证通过后把这个用户平滑迁入自己的数据库。用户完全无感知，不需要重置密码，迁移是渐进式的。
这和从 AWS Cognito 迁出形成了鲜明对比：Cognito 不导出密码哈希，你几乎没有懒迁移的可能。
当然，迁移 Auth0 也有它的复杂性：如果你深度使用了 Auth0 的 Rules/Actions（自定义业务逻辑的钩子），那些逻辑需要手动迁移到 SuperTokens 的等效机制里。如果你使用了 Auth0 的 Organizations 功能，SuperTokens 的 Tenant 模型设计不同，需要仔细对应。
迁移没有零成本，但 SuperTokens 是目前这几个方案里把迁移路径做得最清晰的一个。
—
什么团队适合 SuperTokens
自托管不是对所有人都是正确答案。
如果你是一个两三个人的初创团队，连服务器都还没有稳定的，Firebase Auth 或者 Auth0 的免费层可能是更务实的选择，先跑起来，等到认证费用真的成为负担再考虑迁移。
如果你的应用深度绑定在 AWS 生态，Cognito 的价格优势在规模大了之后还是相当明显的，只要你从一开始就接受不太好迁出这个事实。
但如果你符合下面几个特征，SuperTokens 值得认真考量：
你已经有自己的服务器或容器集群，加一个 Docker 容器不是负担。你的应用是面向企业的 SaaS，多租户隔离是核心需求。你对用户数据主权有明确要求，不想把密码哈希和用户信息存在第三方平台。你的月活用户正在快速增长，或者能预见到 Auth0 的账单增长曲线。
对于这类团队，SuperTokens 自托管版本能在不花额外费用的情况下，提供远超 Auth0 免费层的完整功能集。
—
那些细节
几个实际使用时要留意的地方：
SuperTokens 的 Dashboard UI 比 Auth0 的管理界面简陋不少，功能有但不够精致。如果你习惯了 Auth0 那种完善的管理控制台，初期会有落差感。
社区规模比 Auth0 小很多。遇到非常规问题时，Auth0 的 Stack Overflow 答案库是 SuperTokens 没法比的。SuperTokens 有官方 Discord，响应速度还不错，但覆盖深度不同。
SuperTokens 云托管版本（如果你不想自托管）的定价比 Auth0 便宜，但功能还在持续补齐中，不如 Auth0 成熟。
最后，SuperTokens 是一家小公司，开源项目有被停止维护的风险。不过 MIT 协议意味着即便如此，你 fork 出来自己维护也是合法的。
—
迁移之前，先想清楚一件事
认证是你应用安全的核心。换认证方案不是换一个 npm 包，它涉及到用户密码、会话管理、权限验证，任何一个地方出错，后果都比换错数据库严重。
所以在决定迁移之前，值得问自己：我为什么要换？是因为账单，还是因为功能，还是因为数据主权？
如果只是因为账单，先算清楚自托管的真实总成本再做决定。如果是因为数据主权或功能需求，那 SuperTokens 确实提供了一条可行的路。
越来越多的团队选择 SuperTokens，不是因为它比 Auth0 更好用，而是因为它把”控制权还给你”这件事做认真了。在一个 SaaS 定价越来越不可预测的年代，这本身就是一种价值。
延伸阅读
- AI 企业自动化平台怎么选：Microsoft Power Automate AI vs AWS Bedrock Agents vs Google Vertex AI Agent Builder，2026 大厂押注的三条路，哪条适合你？
- 亚马逊关闭 Mechanical Turk：那个藏着真人的机器，终于不再需要人了
- Okta 替代方案怎么选：Clerk vs Auth0 vs WorkOS vs Descope vs FusionAuth，2026 身份认证该押谁？
Stay updated with our latest AI insights
