你可以在一天內打造自己的身份驗證。這正是陷阱所在。
數十個 B2B 團隊都跟我們說過同樣的故事。起初只是一個簡單的登入頁面。隨著實際流量進來，它無聲地變成了身份基礎設施：整個產品的地基。
它看起來只是一個功能，卻變成了整個身份模型的源頭。
每個自研的身份驗證一開始都只有幾行程式碼。真正的問題是在上線後，當每一個小決定悄悄地變成了整個產品假設的身份模型。
第一天：四十行程式碼
電子郵件、密碼、加密、存儲，登入時比對。簡單搞定。
這正是每個團隊都這麼開始的原因，身份驗證看起來好像只需要一個下午就能完成。
第二百天：無聲的身份模型
誰算是一名用戶。他們隸屬於哪個組織。哪個 session 還可信。如何收回訪問權限。
速率限制、多因素驗證及其恢復流程、會話、刷新 token、一個遠超 is_admin 布林值的組織模型。你發佈的每一個決策，都成了產品悄悄認定的規則。
第五年：你碰不得的基石
紙上換個登入頁，實際要重建整個身份基礎。
一家 20 年的 SaaS 嘗試把用戶名改成郵箱。權限檢查散落在上百個模組。沒人敢批准，所以拖了很久，直到再也拖不下去。
自建身份驗證方案正常運作 —— 直到業務變動
它能安穩地讓大家登入好多年。然後只要有一次業務調整，「夠用」一夜之間變成「礙事」。這三種情境，幾乎每個規模化產品都會遇上。
企業客戶開始要求 SSO
第一份大合約到手，採購部門要自家 Entra 或 Google Workspace 的單點登入。然後還要支援 SAML 跟 OIDC，因為下一家用的是別的。每個客戶的身份配置都不同，很少有工作能直接複用。
- 每個客戶協議不同、欄位對應與憑證輪換都不同
- SSO 不是做一次就好，每簽一間企業都要重做
- 最後成了只有一位工程師懂得全貌的人工作業
身份本來分散，現在必須統一
按組織、產品分開，還常常因併購遺留下來。「統一身份」聽起來像個功能，寫程式時其實要重新定義什麼是一位用戶、一個組織。
- 一個郵箱能屬於多個組織嗎？怎麼遷移舊的用戶名？
- 併購來的九個產品，就有九套身份驗證系統並行
- 一次收回所有產品的離職者權限，還要可稽核
AI 代理和 CLI 開始代表用戶操作
不只人在瀏覽器登入。代理、MCP 伺服器、命令列都會聲稱替用戶操作。但你的身份驗證只會讓人在網頁上登入。
- Token 發給誰、範圍和受眾是什麼？
- 只給一個工具或一份資料權限，之後能回收
- MCP 和 CLI 訪問靠 OAuth，不是登入表單
真正的成本不是寫出來，而是養好多年。
第一版成本很低：幾位工程師、幾週開發，功能就上線。之後每年都要花本來該投入核心產品的工程心力去維持它。
帳單變了，只是改成別的方式付
你永遠不會收到「身份驗證」的發票。
你會付出工程人月、專案延誤、安全性技債和反覆重工。有個會員組織為了省授權費自建身份驗證，五年後維護成本早已超過購買第三方方案。
默默壓在一兩個人身上
關鍵脈絡只存在某人腦中，不在文件裡。
哪個客戶怎麼配置、為什麼遷移這麼做。那個人不在，企業業務就卡住 。他離職，這些知識全跟著一起走。
你想讓工程師在哪發光？
沒客戶會因為你自己寫了 OAuth server 而多付一塊錢。
身份驗證必須可靠。但「可靠」不等於「自己寫」。對大多數產品來說這只是核心依賴，不是競爭差異。兩者完全不是一回事。
如果你不自己寫，該怎麼選？
成熟的身份驗證方案都有這些功能：SSO、多因素、組織管理、統一登入、代理訪問。真正的差別在於能不能退出。別為了逃離幾千行自家程式，換來被另一家廠商綁死。
標準協議，而非自己發明一套
OIDC、OAuth、RS256 簽名的 JWT，你都懂。直接從標準 token 讀取 claims，不需學全新 API。
真正能離開的大門
如果是開源且可自行部署的，想走就能走。別拿自家客製方案，換去一個一樣綁死的託管方案。
計費不鎖定你的用戶數據表
按註冊或月活用戶收費，只會越來越貴。規模化後這就是增長稅，導致團隊寧可自建方案。
你的數據絕不被綁住
想導出用戶數據，隨時都行。把這些敏感資料交給專業團隊，省去你守護一堆 PII 的風險，本來你就不該承擔。