1.24 万 Star 的 Logto，把 OIDC 和 OAuth 这门玄学，做成 SaaS 能直接用的开箱登录

做过 to B 产品的开发者，大概率都被「登录」这件事折磨过。

听起来不就是用户名密码嘛，单拎出来每一项都不难。可一旦开始正经做 SaaS，多租户、企业 SSO、OIDC、OAuth 2.1、SAML、RBAC、MFA、社交登录、密码策略，这些词一个接一个冒出来，每一个背后都是一套协议、一堆边界情况、一摞踩坑记录。

logto-io/logto 想解决的就是这件事。截止 2026 年 6 月 29 日，1.24 万 Star，850 Fork，MPL-2.0 协议，TypeScript 写的。它把自己定位成「modern, open-source auth infrastructure for SaaS and AI apps」，给 SaaS 和 AI 应用用的现代开源认证基础设施。

说白了，它是奔着 Auth0、Cognito、Firebase Auth 这些商业方案去的开源对手。

它赌的是「认证不该是 SaaS 的麻烦事」

先说定位，因为这点决定了一个项目的生死。

认证基础设施这条赛道很拥挤。老牌的 Auth0（被 Okta 收购）、AWS Cognito、Firebase Auth，还有同属开源阵营的 Keycloak、Ory、Super Tokens。Logto 不是最早的，2021 年 6 月建仓，凭什么能涨到 1.2 万星。

我自己的判断是，它押对了两个趋势。

第一个是多租户 SaaS 的标准化。 现在做 SaaS，多租户不再是加分项，是基本盘。Logto 把 organization（组织）这个概念做进了核心，组织级 RBAC、成员邀请、JIT（just-in-time）自动配置，开箱就有。README 的 Showcase 里专门有一段展示多租户和组织功能。这意味着做 B2B SaaS 的团队，不用再自己从零搭一套租户隔离的权限体系。

第二个是 Agent 和 MCP 架构的崛起。 这点是最有意思的。README 里反复出现一句话，「Works out-of-the-box for Model Context Protocol and agent-based AI architectures」，原生支持 MCP 和基于 Agent 的 AI 架构。

你想想看，当 AI Agent 开始代替用户去调用 API，认证的主体就不只是「人」了，还有「Agent」。Agent 怎么拿 token、怎么被授权、怎么隔离，这套问题传统认证方案根本没设计过。Logto 把这块写进了核心卖点，是在赌 Agent 时代会催生全新的认证需求。

这个赌注挺有前瞻性。

协议全覆盖，是底线也是门槛

光说支持协议没感觉，但你要自己实现一套就知道有多疼。

Logto 支持 OIDC、OAuth 2.1、SAML 三大协议。注意是 OAuth 2.1，不是 2.0。2.1 是把 2.0 里那些容易踩坑的最佳实践，强制成了默认值，比如强制 PKCE、移除隐式流程。一个项目愿意上 2.1，说明它在认真做安全，不是糊弄个能跑的版本。

OIDC 是 OAuth 之上的身份层，解决「这个人是谁」的问题。SAML 是企业 SSO 的老牌协议，接 Azure AD、Okta 这种企业身份提供商必须的。这三者全覆盖，意味着从 to C 社交登录到 to B 企业 SSO 一条龙。

社交登录这边，Google、Facebook、GitHub、Apple 这些主流的都支持，还支持 Google One Tap 那种一键登录。密码登录、邮箱验证码、短信验证码、TOTP 双因素，该有的都有。

这套能力如果自己写，保守估计一个团队搞半年。用现成的，docker 一行起。

30 多个 SDK，是真的「集成任何地方」

认证方案好不好用，一半看协议，一半看 SDK。SDK 少一个，开发者就得自己封装，体验立刻打折。

Logto 这块下了血本。README 列了 30 多个框架的 SDK，React、Next.js、Angular、Vue、SvelteKit、Flutter、Go、Python、Node.js，SPA、Web 应用、移动端、API、M2M（机器对机器）、CLI 工具全覆盖。

集成方式也灵活。SPA 用前端 SDK 走授权码流程，后端 API 验 token，移动端走原生 SDK，CLI 工具用设备授权。README 里有个 GIF 动图专门展示「developer-first SDKs，几分钟装好带清晰指南」。

Connectors（连接器）这个设计值得多说一句。各个身份提供商、短信邮件服务商，都抽象成 connector，按需启用。要接 Twilio 发短信、接 SendGrid 发邮件、接 Google 登录，装对应 connector 就行，不动核心代码。这种插件化设计，让生态扩展不污染主干，是成熟开源项目的标准做法。

起步，比想象的简单

本地起一个 Logto，门槛很低。

最省事的是 Docker Compose，一行 curl 拉配置文件再 docker compose up。

# Docker Compose 方式（需要 Docker Desktop）
curl -fsSL https://raw.githubusercontent.com/logto-io/logto/HEAD/docker-compose.yml | \
docker compose -p logto -f - up

# Node.js 方式（需要 PostgreSQL）
npm init @logto

或者直接用 Logto Cloud，全托管零配置，适合想快速试水的团队。

它还提供 GitPod 一键启动和 Render 一键部署，连本地环境都懒得搭的开发者也能秒起。这种「降低上手门槛」的诚意，在开源 infra 项目里是加分项。

开源协议和商业化，一个微妙的平衡

Logto 用的是 MPL-2.0（Mozilla Public License 2.0），这个选择挺讲究的。

MPL 属于弱 copyleft，介于 MIT/Apache 的宽松和 GPL 的严格之间。它的核心条款是「文件级 copyleft」，你修改了 MPL 协议的文件，那些文件的修改必须开源，但你可以在更大的项目里以其他协议链接这些文件。

对企业用户来说，这意味着可以放心用 Logto 做商业产品，不用像碰到 GPL 邢样担心「传染」。对 Logto 自己来说，这个协议既鼓励采用，又保护了核心代码的修改必须回馈社区，比纯 MIT 更有防御性。

搭配 Logto Cloud 的托管服务，这就是一个典型的「开源核心 + 云服务变现」模式。开源版给你自托管的能力，云版省去运维烦恼。这种平衡在 Auth0 们身上早就被验证过，Logto 是在复刻一条被证明可行的路。

自托管的代价，issue 区说了实话

认证这事吹过头容易翻车，所以我把 Logto 的 GitHub 翻了一遍，看看真实用户在抱怨什么。结果比 README 老实得多。

自托管意味着安全自己背锅。 这不是抽象的「你要运维」，是具体的「安全补丁你得自己跟」。Logto 源码 .changeset/ 目录里躺着一条 reject-null-bytes-in-oidc-request-body.md，这是一个 OIDC 请求体里注入空字节的防护修复。这种漏洞普通用户根本不会注意到，自托管就得你自己盯 release、自己升级。出了事没有 SLA 兜底。

RBAC 看着开箱即用，真用起来有边界。 我挖到一个 17 赞的 issue #6842，标题很直白，「Can not create role (and shouldn’t need to, either)」，用户连角色都创建不了，还在吐槽「本不该需要手动建」。还有 28 赞的 #3787「API-based custom sign-up and sign-in」，社区在要 API 级别的自定义登录流。这说明 Logto 的 RBAC 和登录流定制性，在复杂 to B 场景里有真实摩擦，不是 README 演示的「开箱即用」那么顺滑。

企业 SSO 的复杂度在协议之外。 Logto 支持 SAML 没错，但真实世界里接企业客户，每个客户的 IdP 配置、自定义属性映射、合规要求都不一样。协议支持只是起点，「能接住各种奇葩企业配置」才是难点，这部分坑你得自己趟。上面那个自定义登录流的 issue 就是佐证。

1.2 万 Star 对认证 infra 来说不算高。 Keycloak 老牌且有 Red Hat 背书，star 数是它的好几倍。Ory 也在快速增长。Logto 在「开发者体验」和「Agent/MCP 原生」上有差异化，但生态厚度还在积累。选型时别只看 star，要看社区活跃度和你的具体场景。

MCP/Agent 原生这块，还在早期。 README 把它列为卖点，但 Agent 认证的最佳实践本身整个行业都还在摸索。Logto 提供了基础能力，但「Agent 怎么安全地代表用户行事」这个大问题，远没到定论的时候。它是在提前布局，不是已经解决问题。

Agent 时代的「认证解耦」红利

Logto 让我注意到的，不是它又一个开源 Auth0，而是开源 infra 项目的竞争重心正在迁移。

以前比的是「协议全不全、性能好不好」。现在开始比「懂不懂 SaaS 多租户、跟不跟得上 Agent 时代」。认证这种基础设施，正在被上层应用形态的变化重新定义需求。

这种迁移里，最值得偷的设计思想是认证与业务逻辑的彻底解耦。Logto 用 connector 插件化身份提供商、用 organization 一等公民抽象多租户、用独立 SDK 层把认证状态从前端到后端全链路打通，本质上都是把「认证」从业务代码里抽离出去，变成可独立演进、可替换的基础设施层。哪怕你不用 Logto，这个「把横切关注点做成一等公民」的架构判断，放到任何 SaaS 选型上都成立。

谁能更早地把「Agent 认证」「MCP 鉴权」这些新需求做成开箱即用，谁就能在下一代开发者选型时占住位置。Logto 押的是这个方向。

至于它能不能真的吃下 Auth0 的市场，还得看 Agent 时代来得有多快。但方向，我觉得是对的。