轻量 SDK，独立服务
Logto 作为独立的身份验证服务运行，与你的产品完全解耦。它的 SDK 是轻薄的、基于标准的 OAuth 2.1/OIDC 客户端，只负责把你的应用连接到该服务。没有任何东西会把 UI 加会话运行时嵌进你的应用打包产物，因此你可以获得现代身份验证，而不牺牲前端性能。
为什么团队在寻找 Clerk 的替代方案
Clerk 以出色的开发者体验著称，尤其是在 Next.js 生态中。 但随着应用规模扩大、架构需求变得更复杂，团队往往会发现，这种紧耦合、重前端的方案会成为负担。
| 动机 | 实际情况是怎样的 |
|---|---|
| SDK 臃肿与性能问题 | Clerk 的预构建 React 组件确实方便，但它们会把一个沉重的 UI 加会话运行时嵌入你的打包产物。这份代价有公开记录：2023 年 Clerk GitHub 上的一个 issue 测得完整的 clerk-js 包体积为 1.2 MB，而 Clerk 自己的对比文章也承认，在使用预构建组件时，其主包“最多可占应用总体积的 50%”。 |
| 僵化的会话架构 | Clerk 充当用户会话的事实来源。当你构建需要自定义租户路由或机器对机器通信的复杂 B2B 应用时，绕开这种以用户为中心的架构会让人倍感挫折。 |
| 没有自托管选项 | Clerk 是专有的、仅限云端的 SaaS。如果你的软件需要为企业客户提供私有化部署，或者你需要对基础设施拥有完全控制权，Clerk 根本不在选项之列。 |
| 偏离标准协议 | 与企业系统集成的开发者会在 Clerk 的标准协议实现中遇到各种不合常规之处，比如缺少标准的 OIDC 注销端点。 |
| 多应用登录形同事后补丁 | 在自家多个应用之间共享同一次登录，正是 Clerk 变得别扭的地方。卫星域名（Satellite domains）只覆盖同一个 Clerk 应用下、少数几个框架上的 Web 应用，而且登录仍然发生在主域名上。相互独立的 Clerk 应用之间无法共享用户或会话，而原生应用则完全没有官方文档给出的路径。 |
Logto 与 Clerk 有何不同？
按你的方式部署：云端或自有基础设施
大多数团队使用 Logto Cloud，从不需要操心基础设施。但如果你销售的软件要由企业客户私有化部署，就不能硬性依赖第三方身份验证云。Logto 的开源核心作为单个轻量级服务器运行，可以直接打包进你的产品。
默认符合标准
Logto 严格遵循 OAuth 2.1、OIDC 和 SAML。标准的发现文档、标准的注销端点、标准的断言。Logto 的行为与规范要求完全一致，因此与企业系统的集成始终顺畅。
Logto 是适合你的 Clerk 替代方案吗？
我们坚持诚实的定位。Logto 并不适合每一位 Clerk 客户。
什么时候你应该切换到 Logto
- 你需要自托管。也许是严格的合规要求，也许是要把身份验证打包进部署在客户基础设施上的产品。这两种情况 Clerk 都无解。
- 你在构建复杂的 B2B 架构。你需要对机器对机器认证、自定义 API 资源以及组织级角色与权限拥有深度控制。
- 性能至关重要。你正在优化前端打包体积，需要一个轻量的身份验证 SDK。
- 你运营着不止一个应用。Logto 为多应用业务而生：你注册的每个应用，无论 Web 还是原生，都共享同一个中央登录会话。一次登录，处处登录。
什么时候 Clerk 可能更适合你
- 你想要开箱即用的 Next.js“魔法”。如果你的首要诉求是零配置地把预构建 React 组件放进 Next.js 项目，那么 Clerk 在该生态中的开发者体验非常出色。
- 你需要让登录发生在应用内部。Clerk 用它的组件在应用内渲染整个流程。Logto 则遵循标准的 OAuth 2.1 重定向流程 ：用户在托管页面上登录，因为直接在应用内收集凭证（旧的 ROPC 授权方式）已出于安全原因被正式弃用。
Clerk vs. Logto：逐项对比
| Logto | Clerk | |
|---|---|---|
| 关键差异 | ||
| SDK 架构SDK 如何与你的应用集成 | 连接独立身份验证服务的轻薄标准客户端 | 重前端的预构建 UI 组件 |
| 标准 OIDC 合规性服务商对规范的遵循程度 | 严格遵循 OAuth 2.1 和 OIDC | 有限缺少标准注销端点 |
| 多应用单点登录用户登录一次，即可在你的所有应用中保持登录 | 所有注册应用共享中央会话 | 卫星域名仅限 Web，且限于单个应用内 |
| 定价模式套餐如何计费 | 基于令牌免费最高 50K MAU | 基于 MAU，外加功能附加组件 |
| B2B / 多租户服务商如何为组织和租户建模 | 原生以组织为中心的架构 | 以用户为中心的架构 |
| 机器对机器（M2M）服务、API 和机器之间的身份验证 | 原生一等支持 | 关注有限 |
| 部署选项身份验证服务可以在哪里运行 | 托管云、私有云或自托管 | 仅限云端 |
基于截至 2026 年 7 月的公开信息。最新详情请以各厂商官方信息为准。
从 Clerk 迁移
得益于 Logto 基于标准的架构，从 Clerk 迁移到 Logto 十分直接。从 Clerk 导出用户数据，再通过 Management API 导入 Logto。
Logto 可导入多种算法的密码哈希（Bcrypt、Argon2、MD5、SHA1、SHA256 和 PBKDF2，另有遗留选项支持 Node.js 支持的其他格式），因此你通常可以在不强制用户重置密码的情况下完成迁移。
用户导入完成后，把 Clerk 的组件换成 Logto 的轻量 SDK，重新掌控应用的 UI 与性能。
阅读用户迁移指南 →每一次迁移都略有不同。如果指南没有覆盖你的情况，请联系我们，告诉我们你的需求。
常见问题
最好的 Clerk 替代方案是什么？
如果你想要同样现代的开发者体验，又需要更强的架构掌控力（基于标准的 SDK、独立的身份验证服务，以及可自托管的选项），Logto 是首选之一。其他备选包括 Supabase Auth（如果你同时需要 Postgres 后端）或 Auth0（面向遗留企业集成）。
Logto 是开源的吗？
是的。Logto Cloud 是完全托管的服务，与 Logto 的开源版本（13k+ GitHub 星标）运行同一套代码。你可以先用云端、之后再自托管，反过来也可以。
Logto 支持 Next.js App Router 吗？
支持。Logto 为 Next.js 提供 SDK 和文档，包括对 App Router 的支持，而且没有沉重的打包体积开销。
我可以将 Logto 用于 B2B 应用吗？
当然可以。Logto 原生支持多租户组织、基于角色的访问控制（RBAC）和企业 SSO（SAML/OIDC），非常适合复杂的 B2B SaaS 架构。
Clerk 是 Clerk, Inc. 的注册商标。功能对比基于截至 2026 年 7 月的公开信息，最新详情请以各厂商官方信息为准。