你可以在一天內構建自己的認證。這正是陷阱。
無數 B2B 團隊告訴了我們同樣的故事。一開始只是個簡單的登入頁。等到真正有用戶流量進來，這部分就默默地變成了身份基礎設施：整個產品都依賴於其之上。
它看起來只是個功能，結果留下了一整套身份模型。
每個自建認證一開始都是幾行代碼。麻煩是在上線後才開始，每一個小小的決定最終都會默默地固定成整個產品假設為真的模型。
第一天：四十行代碼
郵箱、密碼，加密、存儲、登入時比對。乾淨，搞定。
這正是所有團隊的起點，也是為什麼大家都覺得認證像是可以在一個下午完成的小事。
第二百天：無聲的身份模型
誰算是用戶。他們屬於哪家公司。哪個 session 還值得信任。如何回收訪問權限。
速率限制、多因素驗證和其恢復流程、session、刷新 token、一個比 is_admin 布林值複雜得多的組織模型。你加的每條規則都成為了產品默認依賴的規則。
第五年：無法動搖的基礎
紙上換登入頁，實際上是要重構身份基礎。
有一家運營了 20 年的 SaaS 想用郵箱做用戶名。權限檢查分佈在數百個模塊。沒人敢批准，結果拖了很久也搞不定。
自建認證跑得挺好——直到業務改變
這套系統可以多年無故障地幫人登入。直到某個業務變化讓「夠用」一夜之間變成了「拖後腿」。幾乎所有規模化的產品都會遇到這三件事。
企業用戶開始要求 SSO
第一個大客戶上門，採購要求對接自己 Entra 或 Google Workspace 的 SSO。接著你還要同時支持 SAML 和 OIDC，因為下一個客戶用的是別的。每個客戶的身份配置都不一樣，絕大多數工作都沒法複用。
- 每個客戶都有不同協議、字段映射和證書輪換
- SSO 不是一次性開發。你每簽一個企業就得重做一遍 SSO
- 最後只剩下一個工程師能完全懂這堆手工活
分散的身份現在必須統一
按組織/產品分割，還經常有併購遺留。「統一身份」聽起來是個功能，但對代碼來說意味著徹底定義什麼是一個用戶、一個組織。
- 一個郵箱能屬於多個組織嗎？舊用戶名怎麼遷移？
- 收購來的九個產品意味著九套認證並行運行
- 一次性撤掉所有的離職人員權限，還要能做審計
AI agent 和 CLI 開始代表用戶操作
不再只是人在瀏覽器裡操作。agent、MCP 服務器、命令行也都代表某個用戶行動。但你自建認證只會讓人登入一個頁面。
- token 是發給誰的，有什麼範圍和受眾？
- 授權給單個工具或數據片段，日後還要能撤銷
- MCP 和 CLI 的存取用的是 OAuth，不是登入表單
真正的代價不是開發，而是多年來一直扛著它。
第一版很便宜：幾個工程師，幾週時間，就能上線。但之後每年都要付出本該花在核心產品上的工程人力。
費用沒消失，只是換種方式付了
你不會收到標著「認證」的帳單。
你付出的是人月、延期、遺留安全風險、返工。曾有個會員組織自建認證為了省授權費，五年過去，維護成本遠大於一開始直接買。
只壓在一兩個人身上
關鍵的脈絡只在某個人腦子裡，不在文檔裡。
每個客戶的配置、為什麼過去某個遷移如此設計。當這個人不在時，企業流程就 停滯不前。他要是一走，這些知識也跟著消失。
你的工程師該花在哪？
沒有客戶會因你自建 OAuth server 多付一分錢。
認證必須可靠。但「可靠」不等於「自己造」。對大部分產品來說，它只是核心依賴，不是差異化點。兩者相去甚遠。
如果你不打算自建，應該怎麼選？
大部分成熟的認證已經涵蓋了功能：SSO、多因素、組織、統一登入、agent存取。真正的差別在於你能不能隨時離開。別好不容易從自己寫的幾千行裡「脫身」，結果又被別人家鎖死。
標準協議，不是自造一堆
OIDC、OAuth 和 RS256 簽名的 JWT，大家都熟悉。直接從標準 token 讀取聲明，不需要學任何廠商自定義的 API。
真的能自己走出去的門
如果是開源且自部署，想啥時候遷移都可以。別把自己的系統換成又一個無法退出的托管服務。
計費方式不跟你用戶表掛鈎
按註冊用戶或月活計費只會越收越多。大規模下這就是增長稅，也是讓團隊自己造輪子的動力。
你的數據永遠不會被鎖死
什麼時候都可以導出用戶數據。把這類敏感數據交給專業對口，能避免你本不該承擔的一堆 PII 風險。