你其實可以一天內建好自己的認證系統，然後系統安穩運行數年。但真正的成本，會在你業務改變的那一天浮現。這是來自數十次 B2B 訪談的教訓。
認證看似是個你可以自己完成的小功能。輸入電郵和密碼，加 hash，比對登入。自家造一個認證系統會有幾難？
其實你可以做到。陷阱就在這裡。
我們與數十個團隊聊過他們自家造的認證。大部分找上我們，都是因為：認證系統拖慢了業務。
行業、技術堆棧、規模各異，但結局都一樣——自己開發的認證成了團隊背著的債務。
奇怪的是這個問題不會以服務中斷的形式出現。系統照常讓用戶登入，一切正常，直到某次業務變動卡住發展：安全審查、第一個企業客戶、收購、或需要橫跨兩個產品的新功能。
上星期還「沒問題」。但下一個路線圖上的項目被卡住了。
自家認證最大的錯誤，是把它當作一個功能。你第一天寫得出來。但當有大量真實用戶流量進來時，它就跟你的用戶、組織、權限摻雜起來。
認證不是功能。它是身份基礎設施。
每個自家認證系統開頭都一樣。收電郵和密碼，加 hash，儲存，比登入時對比。四十行程式碼，簡單乾淨。
麻煩在上線後開始。機械人瘋狂註冊，所以你加上速率限制、CAPTCHA、裝置指紋識別。某天 SMS 驗證碼發不出，就加上重發和每日上限。再來會更煩：安全重設密碼、多重認證（MFA）及其回復流程、工作階段與刷新 token，權限模型遠超一個 is_admin 布林值。
每件事本身不難，一個衝刺能做完。但每次推功能，都在替產品回答更大的問題。
這些答案累積起來，就是你產品下意識認定的身份模型：誰算一個用戶、一個人能不能屬於多個組織、企業客戶的身份系統怎麼接駁、有人離開時權限怎麼收回。
你後續推的每個新功能都假定這些答案不變，跑得越久就越難更改。
我們看過一間公司這樣：垂直型 B2B SaaS，做二十年了，服務實體商家。他們十多年前就自家開發認證，各客戶分開登入、權限檢查寫在商業模組裡。當年很合理。
二十年後，他們想做個很小的改動：一個統一登入頁面，電郵作為用戶名。結果根本不是介面沒那麼簡單。那些檢查散落在數百個模組，統一登錄要動用戶模型、組織模型、憑證遷移、每個權限邊界。沒有人敢拍板，拖了好幾年。
當年那個登入頁，看起來像一個功能。留下的卻是整個身份模型。
要公平點說，自家認證通常可以用很久。讓人登入、刷新會話，業務跑好多年。複雜度一點點疊加，總覺得「還掌握到」
但說「夠用」，很可能只是業務還沒撞牆。一旦撞上，問題通常不是認證本身，是旁邊的業務變了，「夠用」一夜間變成「礙事」。
下面這些情景，大部分產品擴展時都會遇到。看似不同，本質如出一轍：業務邁步了，老身份模型跟不上了。
情境：客戶想用自己的 IdP 登入，但你的認證系統壓根沒有「外部身份供應商」這個概念。
第一單大企業合作到手，採購寄來需求文件。先是用 Microsoft Entra 或 Google Workspace SSO。然後兩者都要，因為下個客戶用別的。再來要 SCIM，自動建立和移除員工賬號。
每個客戶配置都不一樣：協議、欄位映射、證書輪換、組織架構的映射方式都不同。
而且這些工作沒啥能重複用。下個客戶帶著新 IdP、新配置，大多要重做。SSO 不是做一次就完的功能。簽下一個大客戶又重來，客戶數越多，成本只會更大。
這時認證再也不是「讓用戶登入你的產品」，而是「讓你的產品接入客戶的身份系統」。完全兩碼子事。
我們見過有公司全靠手動配置 SSO，全公司只有一個工程師搞得懂流程。他在，公司客戶上線。他休假，銷售和導入流程全卡。結果他離職，連知識都帶走了。
當初決定自家開發認證時，根本沒有這些問題。
情境：一開始身份數據分散（按組織和產品分），業務做大你開始需要統一身份。
上面那家公司統一登入時就撞過這個，同一類情況在多產品線也常見。我們合作過一個平台，有 9 個產品（收購來的），各自帶一個認證/用戶資料庫。
收購無法自動合併認證。每收一個產品就是一套認證系統，9 個系統並行僅保養就消耗不少人力。
問題堆起來：A、B 兩產品同一個人算同一個用戶還是兩個？怎麼對齊同一個客戶組織？怎麼授權跨產品功能？員工離職時怎麼一次收回 9 個系統的存取？怎麼審計？
9 個認證本身都沒壞，加起來就是一堵牆。
「統一身份」聽起來就像個功能。實際上是要重定義基礎邏輯：怎麼算一個用戶、一個組織。幾乎每個功能都建在老的定義上，要改意味上層全要動。
情境：登入的已經不只是人，還有 agent、指令列工具（CLI）、腳本用戶要代表某位用戶執行動作，但你的認證系統只認得上網頁登入的人。
代理 agent 需要替用戶呼叫你內部的工具。MCP server 需要安全暴露受保護的資源。CLI 工具無瀏覽器也要查帳號資料。
全都遇到同一類問題：這請求是代表哪個用戶、能訪問哪些資源、token 發給了誰、權限範圍是多少、怎麼撤銷、更該記錄用戶還是代理人？
以人登入的設計，從來沒考慮這些機制。MCP 要靠 OAuth 做授權。CLI 要不經過 OAuth 登入、要不就用可以隨時撤銷的個人存取 token。這些跟傳統登入頁完全無關。
如果你的認證設計只認一人在頁面登入，現在就要開始處理客戶端代表某人來動作了。
前述問題都不是「認證崩潰」。系統還在跑。每個看似小功能，動手即變成策略、數據遷移、客戶交付。
MFA（多重認證）最為明顯。表面上只問「登入後能不能多驗證一次」。
實際設計時要問：哪些組織、用戶必須強制啟用，admin 能不能強制成員啟用，有沒有敏感操作（例如改支付、匯出數據）需要重驗，回復碼如何產生和重設、客服能不能重設、SSO 用戶的 MFA 究竟屬於你還是客戶的 IdP？加 MFA 意味整層安全策略要引入。
「純粹同步用戶」也是同故事：背後連著一串 onboarding、offboarding、跨組織成員資格決策，全都假設你的用戶與組織模型一開始設計就對。
越加越多功能，反而在你產品內養起一套身份產品。第一個版本很便宜、幾個工程師幾個星期。往後年年都得繼續投。
自建最大理由是省成本，而且這樣想也沒錯。
其中一間我們深訪過的會員組織，五年前算過一筆賬。他們有十幾萬會員，常登入的只有幾千位。廠商按會員數收費，報價超支，自己做更便宜。當年算的，確有道理。
五年後，數字翻轉了。維護登入和保安全的投入，超過直接購買。
第一年省下的發票可見，工程時間不可見。第五年，省下的開支數字沒變，但工程時間變成路線圖延遲、安全債、沒人想維護的系統。
自家做認證不是免費。只是你收不到「認證月費」的發票。你付出的是人月、延遲、重工、安全債，以及原本該花在核心產品的工程心力。
維護 SSO 的老工程師不是獨例。自家認證養得久了，關鍵上下文會淤積在一兩個人腦裡。哪個客戶怎麼設、哪個欄位動不得、過去某次遷移背後的原因——這資訊很少進文件，就活在某人腦裡。
他在，推進如飛。他不在，企業單卡住，最後你發現公司最關鍵基礎設施沒有 owner，只有「那個懂的人」。
有些團隊甚至做了給客戶自助配置 SSO 的平台。表面很成熟，但實際問問到底有多少客戶用？我們見過 150 萬月活產品，這套系統只服侍十多個客戶。
你以為你在做一個功能，實際是在養內部產品，但攤分給十多個客戶。如果身份是你的主業，值得。如果不是，就是本最純粹的隱形賬單。
再說那家二十年 SaaS。不是沒有實力，他們靠著產品服務活了這麼久，足證工程真的懂客戶。
這才是問題所在。問白點，你要他們人手維護客戶 SSO，掏數百模組挖二十年權限邏輯，還是更專注深耕行業軟件本身？
這不是工程完美主義，而是資源分配。如果你在做帳單、垂直 SaaS、會員入口、營運軟件，沒一個客戶會因為你自寫 OAuth 伺服器多付一分錢。
有個做帳單的團隊說得很直接：自家 IdP「也還行」，但這是策略選擇。認證不多寫，精力留給把帳單做到極致，其餘用最成熟的現成認證方案。
認證要可靠。但「可靠」不等於「一定要你親手寫」。資料庫、郵件推送、雲服務也都得可靠，成熟團隊不會因為某個東西很重要就覺得一定要自家搞。
對大部分產品而言，認證是核心依賴，但不是差異化優勢。除非身份就是你的主業，否則在自己產品裡養身份平台不是護城河，而是長遠資源消耗。
很容易就走極端：認證程式碼一行都別寫。這也不對。
某些階段自建（或半自建）很合理：內部 Demo、超早期原型、一次性驗證項目。如果你業務有極為專門的權限需求，現成平台真的無法實現，保留那部分自己做，但認證、會話、SSO、MFA、用戶目錄都交給外部平台，此舉完全沒問題。
只是要小心 POC（概念驗證）滑坡。常見路徑是兩個開發花六八個月寫原型對接外部系統。技術策略沒錯，本身東西很好，只是根本沒打算承載規模。
而 POC 是最容易硬化成長期架構的。一轉眼半年變「現行方案」，兩年叫「舊系統」、五年變「動不了的基建」。擺脫自家認證的最佳時機通常不是等它壞掉，而是免得它變根基。
所以界線在這裡：問題不在於你有沒有寫過認證程式碼，而是你是否接手了通用身份基礎設施並讓它安家在自己團隊。
邊緣需求自己解決，核心身份層要小心。別不知不覺養出一整個 CIAM 平台。
如果決定不親自寫，下一個問題是：買哪家的，怎樣選？
主流方案功能大致都齊：SSO、MFA、多組織、統一登入、代理存取。所以真正的分野不在功能表。
最容易忽略，但最值得比較的，是這幾點。全都聚焦一個重點：別好不容易逃出自家自寫的幾千行，卻又被另一套出不來的系統困死。
公開聲明：Logto就是我們按這四點造的認證產品。它開源可自管，也有雲端託管版：要零維護用雲，要完全掌控可自管，而且隨時想遷出，門隨時打開。
標準 OIDC 下開箱即用支持登入、MFA、SSO、RBAC，帳單看 token 用多少，實際按需付費。
外面也有很多成熟方案，認證從沒唯一正確解。若你在評估，我寫過一篇如何選認證方案 詳談可參考。
第一天自家認證通常沒問題。問題是日後它會發展成底層基建。
業務每新增一步都得重檢視：企業要 SSO、安全要 MFA、產品想統一登入、多產品要連接、AI 代理要替用戶存取資源。這些小功能背後都藏著一連串策略，年年耗費原本該搞主線產品的工程成本。
這張賬單不會第一天就寄來。常常多年後才浮現。到那時你才恍然：當初寫的登入頁，其實已經是要伴隨產品一生的身份基礎設施。
認證多半不是你核心業務。看清這點越早，你就越能把人力、資源和精力集中在真正的主線產品。
不是。早期 demo、內部工具、一次性驗證或極專用細緻權限分工，現成方案表達不了，都很合理。但要避免的是沒察覺地扛下長期的通用基建，讓它永遠待在公司日常維護範疇內。
認證回答「你是誰」。授權回答「你能做什麼」。在真 SaaS 裡兩者很難切割：用戶、組織、角色、權限、會話、token claim、審計紀錄全都交織。所以你換認證系統，不能只看登入頁。
因為這意味要讓你產品嵌入客戶自己的身份體系。不同客戶用不同 IdP、協議、claim 欄位、證書、組織對應法。接上第一個並不意味可複製。多半真的只有一人「手動」搞定。
可以。只是一次性割接通常不是辦法。分層遷移：從新用戶、登入和企業 SSO 先導入身份平台，現有用戶下次登錄時再遷移。要從始到終都保留回滾方案和審計，不要讓遷移變不可逆。