简体中文
为什么你不应该自行构建认证系统：来自数十位客户访谈的经验教训
你可以在一天内搭建自己的认证系统，并让它稳定运行多年。真正的成本在于多年后业务变动的那一刻才显现出来。这里是我们在数十次 B2B 访谈中得到的教训。
Yijun
Developer
Developer
你可以在一天内搭建自己的认证系统，并让它稳定运行多年。真正的成本在于多年后业务变动的那一刻才显现出来。这里是我们在数十次 B2B 访谈中得到的教训。
认证看起来像是件你自己就能搞定的事。邮箱、密码、哈希一下，登录时校验。自建一套认证系统能有多难？
你当然可以。这就是陷阱所在。
我们和几十个团队聊过他们自己搭建的认证系统。绝大多数因为同一个原因来找我们：这个系统正在拖累他们的业务。
不同的行业、技术栈和规模，但结局如出一辙：他们自建的认证成了团队一直背负的技术债务。
奇怪的是，这种问题从来不会以“故障”爆发。系统照常帮用户登录，运行良好，直到有一天业务变动把路堵死了：安全审查、第一个企业客户、收购、横跨双产品的新功能…
上周还“一切正常”。结果下一个 roadmap 任务卡在了认证系统后面。
自制认证最大的问题就是把它当成了一个功能。你上线第一天的确能写好它。但一旦真有用户量通过，它就和用户、组织和权限体系纠缠在一起。
认证不是一个功能，而是身份基础设施。
所有自建认证系统起步都很类似。收一个邮箱和密码，哈希、存储、登录时校验。四十行代码，干净利落。
麻烦在上线后开始了。机器人疯狂攻击注册接口，你开始加限流、加验证码、设备指纹。短信验证码突然发不出，你又要补重发、每日上限。更棘手的来了：安全的密码重置，多因素认证及其恢复流程，Session 和刷新 Token，一个绝不是is_admin布尔值那么简单的权限模型。
单个问题都不算难，每项需求都能安排进一个 Sprint。但每实现一项，你就要为产品回答更抽象的问题。
所有这些答案叠加，就构成了你产品默认视为“既定事实”的身份模型：什么样算一个用户、一个人是否能属于多个组织、企业客户的身份系统如何对接、一个人离开时怎么收回访问权限……
你后来写的所有功能，都自动依赖这些答案。系统运行时间越长，想改动这些答案就越难。
我们在一家老牌垂直 B2B SaaS 公司看到过这个场景：二十年历史，服务实体门店运营商。十余年前自建认证，做到每个客户独立登录、权限写进业务模块。当初的确是合理选择。
二十年之后，公司希望做个小改动：“统一登录页，邮箱当用户名”。结果发现这根本不只是个页面的事。各项权限分散进几百个模块，统一登录牵动用户模型、组织模型、凭证迁移，每一道权限边界都要重新摸索。没人敢拍板，这一拖就拖了很多年。
刚写认证时，它看起来只是个功能。后来遗留下来的却是一整套身份模型。
公平讲，自建认证通常用很久，能帮多人登录、刷新 Session、支撑日常业务好多年。系统的复杂度积累得很慢，一点点长出来，你总觉得还 controllable。
但能“用下去”，往往只是业务还没撞上那堵墙。一旦撞上，问题多半早已不是认证本身。周边业务发生了变化，昨天的“够用”说变就变成了“最大阻碍”。
下面这些场景，大部分产品发展到中后期都会遇到。看似不同，其实本质都是：业务在进化，老的身份模型赶不上节奏了。
场景：客户希望用自己的 IdP 登录，而你的认证系统完全没有“外部身份提供方”这个概念。
第一个企业大单拿下，采购部门寄来需求清单。先要用 Microsoft Entra 或 Google Workspace SSO，再要求 SAML、OIDC 两套协议，因为下一个客户用的是别的系统。最后要求支持 SCIM，实现自动员工账号的增删。
每个客户的集成都不一样：协议、字段映射、证书轮换、组织结构对接方式全都不同。
而这些工作基本都不能复用。下一个客户再来就是全新配置，全新流程。SSO 不是“一次性功能”，每签一个大客户就要再做一次，客户越多，集成成本随之飙升。
认证系统已经不再是“让用户登录产品”了，而是“让你的产品能插进客户的身份体系”。这完全是两件事。
有家公司 SSO 全靠手工配置，全公司只有一个工程师“全流程理解”。他在，客户能上线。他休假，销售和对接全部停滞。他走了，连知识一起流失。
这些都没人会在决定自建认证时提出来。
场景：身份数据最初分散、按组织按产品存储，随着业务扩张，你开始需要统一身份。
前述那家二十年老公司遇到过。我们也接手过一个平台，收购了九个产品，每个都有独立用户池、认证栈。
收购本身不会合并身份系统。你收一个产品，就要维护多一套认证栈。九套并行的话，仅运维都要专门人力。
问题接二连三：同一个人在产品 A/B 里算是同一个用户还是两个？同一客户组织怎么做跨产品映射？跨产品授权怎么做？员工离职怎么一次性收回九个产品的权限？审计怎么做？
九套互不影响，但加在一起就是道墙。
“统一身份”表面只是个需求，实际却是推倒最基础的数据定义：什么算一个用户，什么算一个组织。几乎所有现有功能都写死在旧定义上，想调一次就是地基全盘挪动。
场景：现在不止有人用浏览器登录，Agent、命令行、脚本都自称代表某用户，但你的认证系统只理解页面登录。
Agent 要帮用户调用你们的内部工具。MCP 服务端需要安全暴露资源。CLI 工具要查账户数据，没浏览器。
问题都是一类：请求到底代表哪个用户，能访问哪些资源，这个 Token 是发给谁，用途和范围是什么，怎么吊销，日志记用户还是记 Agent？
老系统没有为这些客户端设计机制。MCP 依赖 OAuth 授权，CLI 要么走 OAuth 登录，要么配个人访问 Token，能随时吊销。这些流程都和页面登录毫不相关。
如果你的认证系统只考虑“用户页面登录”，现在就要补进“Client 代表用户行为”这一整个链路。
上述任何一项都不是“认证挂了”。系统照样在跑。每个看起来是小功能，真做起来牵涉到产品策略、数据迁移、客户交付。
比如多因素认证（MFA）特别典型。表面上就是“登录后再验证一次”。
才做两步，马上涉及：哪些组织/用户强制要求？管理员能不能统一开？敏感操作（比如改付款，导出数据）是否需单独再验？恢复码谁来生成和重置？客服能不能协助重置？SSO 用户 MFA 算你的还是客户 IdP 的？MFA 新增其实就是引入一套完整的安全策略层。
“把若干用户同步一下”同样复杂：背后全是用户、组织模型设计是否一开始就正确的判断。
功能越多，你就越像在产品里维护了一个身份产品。第一版很便宜，几个人几周。后面年复一年都要“喂养”下去。
自建最常见的理由就是成本，而且绝不天真。
我们采访过一家有会员业务的公司，五年前算过一笔帐：总会员数十万，活跃登录才几千。第三方认证厂商按会员数计费，报价远超预算，结果他们自建最划算。短期内，没选错。
五年后，形势反转：自维护登录及其安全，累计花的钱远超买方案。
第一年，省下的账目明明白白，工程师时间算不清。第五年时，省下的钱没变，但工程师时间攒成了延期、隐性安全债、没人愿意接手的维护。
自建认证不是“免费”。只是你永远收不到一句“认证订阅费”的账单，而是按人月数、延期、反复返工、安全债和本该砸在核心产品上的工程力零敲碎打地付掉的。
那个手动维护 SSO 的工程师绝非偶然。自建体系用久了，核心上下文几乎都会“堆在一两个工程师头上”：哪个客户配了什么、哪些表字段绝不能乱动、过去的迁移为何那么做。这些很少有人写进文档，全在脑子里。
他在，客户能上线。他不在，企业线索停发。你会发现最重要的基础设施实际上没有 owner，只有“唯一懂的那个人”。
有些团队甚至会自己做给客户用的自助 SSO 配置平台。听起来很先进，但细问一下服务了多少客户？我们见过一家 150 万月活产品，自维护一整套系统，只服务了十几个客户。
本以为是做个功能，实际上是做了内部身份产品，最终摊薄到十来个客户头上。如果身份就是你业务，那值。如果不是，这就是“隐性账单”的典型。
回到那家二十年垂直 SaaS。绝不是弱工程师。能撑行业产品二十年，说明足够懂客户、懂业务。
问题就在这。不好听点说：你花工程师维护每家公司 SSO、从几百个模块抠二十年权限逻辑，还是让他们潜心做行业软件？
这不是“洁癖工程师”，本质是资源配置。你做账单、垂直 SaaS、会员门户、运营工具，没有哪家客户会因为你自写 OAuth 服务器多给你一分钱。
有个做账单的团队就很直接：自家 IdP 没啥毛病，但这是战略决策。认证代码只写最必要的，把精力省下来做账单产品本身，“认证就用市面最成熟的方案”。
认证必须可靠。但“可靠” ≠“自行开发”。数据库、邮件网关、云服务都要可靠，成熟团队不会因为事大事急就都自己写。
绝大多数产品，认证都是核心依赖，而不是决胜点。除非身份本身是你业务，否则在自有产品里做完整身份产品，大概率只会长期消耗你的资源。
容易走极端：认证代码一行都别写。这也错。
某些阶段，自己做没问题，甚至更合适：内部演示、早期原型、一次性验证项目。如果你的业务在授权（特别细粒度）上真有第三方无法覆盖的特定需求，那让外部平台管认证、Session、单点登录、MFA、用户目录，自家只做其中授权也没什么不可以。
只是要小心“POC 坡”。典型案例：两个开发用了半年时间集成第三方搞个原型，本身没问题。团队也说做得不错。但它本来没打算撑规模。
而原型最容易变成长远架构：六个月称“现有方案”，两年后成“遗留系统”，五年后彻底变成“我们不敢动的基础设施”。退出自制认证的最佳时机，其实是“它还没变成基础设施时”。
所以关键不是你写了几行认证代码，而是你是不是把通用身份基础设施变成了团队的长期维护项。
边缘功能放心自己做，核心身份层一定要慎重。千万别不知不觉里，造了一整套 CIAM 平台。
不打算自己写，接下来问题来了：选谁的？怎么挑？
大部分成熟方案功能早就齐全：SSO、MFA、多组织、统一登录、Agent 接入。所以区别不会只体现在“功能列”。
更值得比较的是下面这些点，本质只有一个：别从写的那几千行代码里爬出来，结果又被另一个系统锁死。
坦白说：Logto 就是我们按这四点做的认证产品。它开源、支持自部署，也有云服务：用云免维护，自己部署有绝对主权，随时都能迁移。
标准 OIDC 协议下，登录、多因素认证、SSO、RBAC 都能开箱即用，账单按 Token 计费，用多少付多少。
市面还有不少成熟产品，认证本来就不是只有一个“对”的答案。如果你在选方案，也可以看我写的如何选择身份服务商。
第一天自建认证，理由都站得住脚。最大坑在于它后面会变成基础设施。
企业客户要 SSO，安全方要 MFA，产品要统一登录，多产品互通、AI Agent 调用——每个看似“小功能”背后都是一串策略问题。年复一年养下去，消耗的其实都是本该投入核心产品的工程时间。
这笔账，第一天不会出现。通常是多年后才直观地看到。当年写的那个登录页面，其实早就是一层要撑全产品生命周期的身份基础设施。
认证大概率不是你的核心业务。越早认清，越早能把时间、精力、资源回归你真正在做的产品。
不是。早期演示、内部小工具、一次性验证项目、极为特殊的授权需求，第三方不支持时都可以自建。唯一要避免的，是不小心背上长期、通用身份基础设施的维护责任。
认证回答“你是谁”，授权回答“你能做什么”。实际 SaaS 里，这两者很难区分：用户、组织、角色、权限、Session、Token Claims、审计日志全都高度交错。所以迁移认证系统不能只看登录页。
因为这意味着你的产品要接入客户自己的身份体系。每家客户用的 IdP、协议、Claims 字段、证书、组织映射都不一样。第一个能接通完全不代表其余都能复用，实际都得手动，一个工程师全权掌控。
完全可以。但别一次性切换。分层迁移：新用户注册/登录、企业 SSO 先接到新平台，老用户等下次登录时再迁移。全程保留回滚和审计，确保迁移过程永远“可逆”。