你可以一天内搭建自己的认证系统。这正是陷阱所在。
数十个 B2B 团队都跟我们讲过类似的故事。一开始只是一个简单的登录页面。随着真实流量的到来，它悄悄演变成身份基础设施，成为你整个产品赖以运行的基础。
它看起来只是一个功能，最后却变成了一整套身份模型
每一个自研认证系统最初都只是一小段代码。真正麻烦从上线后开始，每一个小决策都会悄然固化成整个产品默认的身份模型。
第一天：四十行代码
邮箱、密码、加密存储，登录时比对。简单，搞定。
大多数团队都是因此选择从这里开始，这也是认证看起来像是可以一下午完成的原因。
第两百天：悄然成型的身份模型
什么算作用户。归属于哪个组织。哪个会话还可信。如何收回访问权限。
限流、MFA 及其找回流程、会话、刷新令牌、比 is_admin 更复杂的组织模型。你每一次上线的答案都变成了产品默认的新规则。
第五年：动不了的基础
纸面上换个登录页，代码里却是重新搭一套身份基石。
一家运营 20 年的 SaaS 试图改用邮箱作用户名。权限校验散落在数百个模块里。没人愿意拍板，所以拖到最后也动不了。
自研认证没问题，直到业务变化
它能让用户多年顺利登录，毫无事故。直到一项业务变化，让“够用”一夜之间变成“卡脖子”。以下三种变化，几乎每个做大规模的产品都会遇到。
企业客户开始要求 SSO
第一个大客户签约，采购方要求用自己的 Entra 或 Google Workspace 登录。之后还要支持 SAML 和 OIDC，因为下一个客户用的是别的系统。每家客户的身份集成都不一样，几乎所有工作都不能复用。
- 每个客户都有不同的协议、字段映射、证书轮换
- SSO 不是一次性建设，每签一个企业客户都要重做一遍
- 慢慢变成只有一个工程师懂得从头到尾的手工活
分散的身份需要被统一
按组织、按产品分割，甚至是收购继承下来的。“统一身份”听起来像是个功能，但代码层面你得重新定义什么是同一个用户和同一个组织。
- 同一个邮箱能属于多个组织吗？历史用户名怎么迁移？
- 收购来的九个产品就是九套认证系统并行运行
- 一次性注销所有系统的离职成员，并能集中审计
AI 助理和 CLI 工具开始以用户身份操作
用户不再只是通过浏览器登录。AI 助理、MCP 服务器、命令行都要代表某个用户行动。而你的认证系统只会让人登上一个网页。
- 令牌签发给谁，scope 和 audience 如何确定？
- 只授权一个工具或一部分数据，并且随时可撤销
- MCP 和 CLI 访问用的是 OAuth，不是登录表单
真正的成本不在于搭建本身，而是负担多年维护
第一版只要几个工程师和几周时间，就能上线。之后则每年都要投入本该用于核心产品的时间来“喂养”它。
账单换了种方式支付
你永远不会收到一张“认证系统服务费”发票。
你用人月、延误、技术债和反复返工来为它买单。某会员组织为省授权费用自研认证系统；五年后，维护它的成本已高过直接购买。
最后只靠一两个人撑着
关键知识只在某个人头脑里，不在文档中。
哪个客户配的什么，为什么以前这样迁移 。那个人休假就拖慢企业客户进展，离职就带走了全部上下文。
你希望工程师的时间花在哪里？
没有客户会因为你自写 OAuth 服务器而多付一分钱。
认证必须可靠。但“可靠”不等于“非做不可”。对大多数产品来说它是核心依赖，不是核心竞争力。这两者相差甚远。
如果不自研，该如何选择？
主流认证方案都能覆盖功能需求：SSO、MFA、组织、统一登录、代理访问。真正的区别在于你能否自由迁移。别费劲从你自己的几千行代码里爬出来，又被套牢进别家的平台。
采用标准协议，而非自创栈
OIDC、OAuth、RS256 签名 JWT，你都懂。直接从标准的令牌获取声明信息，无需学习厂商专属 API。
一扇真正可以随时离开的门
只要开源且可自托管，你随时能迁移走。别用你的定制系统去换一个你同样无法退出的托管服务。
计费不绑定用户表
按注册用户、活跃用户计费意味着用户表只会增长。规模化后这就是“成长税”，也是团队自研认证的真实动力。
你的数据永远归你
你随时可以导出用户数据。把这类敏感数据交给专业方案，还能帮你规避本不该承担的 PII 风险。