认证系统最容易被低估：登录只是入口，真正影响 SaaS 架构的是用户、组织、角色、权限、会话、SSO、审计和数据迁移。MVP 阶段可以先接入托管服务，但要避免把核心业务模型完全锁死在供应商的用户对象里。
本文只讨论 Web SaaS 常见的身份认证和用户管理方案，价格、免费额度和高级功能以官网为准。
先分四类
| 类型 | 代表 | 适合场景 |
|---|---|---|
| 托管身份平台 | Clerk、Auth0、PropelAuth | 快速上线登录、组织、SSO 和用户中心 |
| BaaS / 云身份服务 | Supabase Auth、Firebase Auth、Amazon Cognito | 已经使用对应云生态，想快速接入登录和用户管理 |
| 可自建身份平台 | Logto、Keycloak、Authelia | 希望掌握部署、数据和 OAuth/OIDC 服务 |
| 应用内认证库 | Better Auth、NextAuth | 愿意自己管理数据库、会话和认证流程 |
如果你的产品只需要邮箱注册、Google 登录和一个个人设置页，应用内认证库就够了。如果从第一天就要支持 B2B 组织、企业 SSO 和管理员控制台，托管身份平台往往更快。
总表
| 项目 | 形态 | 组织 / 多租户 | 自建 | 适合场景 | 主要代价 |
|---|---|---|---|---|---|
| Clerk | 托管身份平台 | 强 | 否 / 以托管为主 | Next.js、B2B SaaS 和快速做出用户中心 | 供应商绑定较深，数据迁移要提前规划 |
| Auth0 | 托管身份平台 | 强 | 以托管为主 | 企业身份、SSO 和复杂连接器 | 配置项和定价层级较多 |
| PropelAuth | 托管身份平台 | 强 | 否 / 以托管为主 | SaaS 团队、组织和团队成员管理 | 适用范围集中，需确认框架支持 |
| Supabase Auth | BaaS 身份服务 | 通过项目和 RLS 扩展 | 否 / 云端为主 | 已经使用 Supabase 的 Web SaaS | 与 Supabase 生态结合紧，迁移要规划 |
| Firebase Authentication | BaaS 身份服务 | 通过 Security Rules 和自有后端扩展 | 云端 | 移动端、实时应用和 Google 生态 | NoSQL、规则和供应商绑定需要理解 |
| Amazon Cognito | 云身份服务 | User Pool、Group 和 IAM 生态 | AWS 托管 | 已经使用 AWS，需接入企业身份 | 配置、概念和排障成本较高 |
| Logto | 身份平台 | 强 | 是 | OAuth/OIDC、组织和自托管 | 需要自己承担部署、升级和安全运营 |
| Keycloak | 开源 IAM | Realm、Group、Role | 是 | 企业 SSO、OIDC/SAML 和自托管 | 运维、升级和资源成本较高 |
| Better Auth | 应用内 TypeScript 库 | 通过插件扩展 | 是 | Next.js、Node.js 和希望掌控数据库的团队 | 认证、邮件、风控和运维要自己组合 |
| NextAuth | 应用内认证库 | 需要自己设计 | 是 | Next.js 项目接入 OAuth 和会话 | 不负责完整的 SaaS 用户管理产品 |
| Authelia | 自托管认证网关 | 组织能力有限 | 是 | 内部服务、反向代理和 SSO | 不适合作为面向客户的完整用户中心 |
Clerk：最快做出可用的 SaaS 用户系统
Clerk 提供登录组件、用户资料、会话、组织、成员、角色和组织切换等能力。对 Next.js 项目来说，集成速度快，适合先把注册、登录、团队邀请和用户中心跑起来。
Clerk 的组织功能适合 B2B SaaS：一个用户可以属于一个或多个组织，组织可以有成员、角色和管理员。数据隔离仍然要在你的数据库和 API 层完成，不能因为前端显示了当前组织就认为权限已经安全。
推荐做法是：
- Clerk 负责身份、会话和组织成员；
- 你的数据库保存
organization_id、业务角色和资源归属； - 后端每次根据会话确认组织和资源权限；
- Clerk 的
user_id和organization_id只作为外部身份标识。
Auth0：企业身份和连接器优先
Auth0 的优势是协议、连接器和企业身份场景较完整，适合需要 SAML、OIDC、企业目录、组织级登录体验或多个身份源的产品。
它的能力也意味着更多配置和概念：Tenant、Application、Connection、Organization、Action、Role 等对象要分清。Auth0 Organizations 的可用能力还与套餐和合同有关，B2B 功能上线前要核对具体计划。
如果产品主要面向个人用户，Auth0 可能显得偏重；如果目标客户是企业，提前选择 Auth0 或同类企业身份平台，通常比后期补 SSO 更容易。
PropelAuth：SaaS 团队功能优先
PropelAuth 更聚焦 SaaS 的用户、组织、邀请、团队成员和 B2B 管理体验。它适合不想自己拼装“登录 + 组织 + 邀请 + 管理员”的早期团队。
重点核对：
- 是否支持你的前端和后端栈；
- 组织、角色和权限是否能映射到自己的数据模型；
- 用户数据导出和迁移能力；
- 企业 SSO、域名验证和审计日志是否在当前计划中。
Logto：OAuth/OIDC 和自托管之间的平衡
Logto 基于 OAuth 2.0 / OIDC，支持登录、应用、组织、组织角色和企业 SSO 等能力，也可以自托管。它适合希望使用标准协议、同时保留部署控制权的团队。
自托管身份系统不能只看“能不能启动”：还要负责密钥轮换、数据库备份、邮件发送、域名、升级、漏洞修复、会话撤销和监控。没有持续运维能力时，托管方案往往更省心。
Supabase Auth、Firebase Auth 和 Cognito：跟着云生态走
Supabase Auth 适合已经使用 Supabase 数据库、Storage 或 RLS 的团队；Firebase Authentication 适合移动端、实时应用和 Google 生态；Amazon Cognito 则适合已经把基础设施放在 AWS 上的团队。
这类方案的优势是身份、数据库、函数和权限规则容易放在同一生态里，代价是迁移和跨云复用成本更高。不要只看登录页面是否接通，还要先确认用户导出、组织模型、企业 SSO 和本地权限映射。
Keycloak：自建 IAM 的主流选择
Keycloak 是成熟的开源身份与访问管理平台，覆盖 OIDC、OAuth 2.0、SAML、Realm、Group 和 Role，适合企业 SSO、内部平台和希望完全自托管的团队。
它的能力比应用内认证库更完整，但也意味着需要自己负责数据库、集群、密钥、升级、备份、监控和安全响应。个人用户 MVP 通常不必从 Keycloak 开始。
Better Auth 和 NextAuth：把认证放进应用
Better Auth 是应用内 TypeScript 认证库，提供邮箱密码、社交登录、Magic Link、Passkey 等能力，并通过插件扩展组织、管理员、SSO 和其他功能。它适合希望自己掌握用户表、会话表和数据库迁移的团队。
NextAuth 更像是 Next.js 生态里的认证接入层，适合快速连接 OAuth Provider 和管理 Session。它不是完整的用户管理后台，也不会替你决定多租户数据隔离和业务权限模型。
选择应用内库时，要把以下工作算进成本：
- 邮箱验证、找回密码和登录异常处理；
- OAuth State、PKCE、回调 URL 和密钥管理；
- Session、Refresh Token、注销和多设备策略；
- 防暴力破解、验证码、风控和审计；
- 用户导出、删除和隐私合规。
认证和授权不要混为一谈
认证回答“你是谁”，授权回答“你能做什么”。推荐至少分出三层：
| 层级 | 示例 | 存放位置 |
|---|---|---|
| 身份 | 用户 ID、邮箱、登录方式 | 身份平台或用户表 |
| 组织成员关系 | 用户属于哪个组织、组织角色 | 自己的数据库 |
| 业务权限 | 能否查看某个项目、修改账单或导出数据 | API / 数据库策略 |
B2B SaaS 不要只用一个 is_admin 字段解决权限。可以先从组织角色开始，再根据产品复杂度增加资源级权限、项目成员和自定义角色。
怎么选
| 情况 | 推荐 |
|---|---|
| Next.js MVP，想最快上线登录和用户中心 | Clerk |
| 目标客户需要企业 SSO 和多种身份源 | Auth0 或 Logto |
| 重点是 SaaS 组织、邀请和成员管理 | Clerk、PropelAuth 或 Logto |
| 希望自托管且采用标准 OAuth/OIDC | Logto |
| 已经使用 Supabase、Firebase 或 AWS | 优先评估 Supabase Auth、Firebase Auth 或 Cognito |
| 企业 SSO 且必须自建身份中心 | Keycloak 或 Logto |
| 希望用户和认证数据完全进入自己的数据库 | Better Auth |
| 只是给 Next.js 接 OAuth 登录 | NextAuth |
| 内部服务统一登录和反向代理保护 | Authelia |
迁移和安全检查清单
- 记录外部用户 ID，不要把供应商 ID 当作不可变业务主键；
- 设计用户、组织、成员和角色的本地映射表；
- 确认供应商是否支持完整导出用户和组织数据；
- 生产环境启用 MFA、域名验证和登录告警；
- 将 OAuth Secret、JWT Secret 和 Webhook Secret 放进密钥管理；
- 后端每个资源接口都执行组织和资源级鉴权；
- 规划删除用户、导出数据和撤销所有会话的流程。
结语
认证方案的第一选择不是“最强的产品”，而是你愿意承担多少身份基础设施。个人用户 MVP 可以从 Clerk、Better Auth 或 NextAuth 开始；B2B SaaS 要优先看组织和 SSO；需要自建时，再把 Logto、Better Auth 和 Authelia 放到对应层级比较。