為什麼你不應該自行開發認證系統：來自數十次用戶訪談的教訓

認證看似是個你可以自己完成的小功能。輸入電郵和密碼，加 hash，比對登入。自家造一個認證系統會有幾難？

其實你可以做到。陷阱就在這裡。

我們與數十個團隊聊過他們自家造的認證。大部分找上我們，都是因為：認證系統拖慢了業務。

行業、技術堆棧、規模各異，但結局都一樣——自己開發的認證成了團隊背著的債務。

奇怪的是這個問題不會以服務中斷的形式出現。系統照常讓用戶登入，一切正常，直到某次業務變動卡住發展：安全審查、第一個企業客戶、收購、或需要橫跨兩個產品的新功能。

上星期還「沒問題」。但下一個路線圖上的項目被卡住了。

自家認證最大的錯誤，是把它當作一個功能。你第一天寫得出來。但當有大量真實用戶流量進來時，它就跟你的用戶、組織、權限摻雜起來。

認證不是功能。它是身份基礎設施。

登入介面背後是一整套身份模型#

每個自家認證系統開頭都一樣。收電郵和密碼，加 hash，儲存，比登入時對比。四十行程式碼，簡單乾淨。

麻煩在上線後開始。機械人瘋狂註冊，所以你加上速率限制、CAPTCHA、裝置指紋識別。某天 SMS 驗證碼發不出，就加上重發和每日上限。再來會更煩：安全重設密碼、多重認證（MFA）及其回復流程、工作階段與刷新 token，權限模型遠超一個 is_admin 布林值。

每件事本身不難，一個衝刺能做完。但每次推功能，都在替產品回答更大的問題。

這些答案累積起來，就是你產品下意識認定的身份模型：誰算一個用戶、一個人能不能屬於多個組織、企業客戶的身份系統怎麼接駁、有人離開時權限怎麼收回。

你後續推的每個新功能都假定這些答案不變，跑得越久就越難更改。

我們看過一間公司這樣：垂直型 B2B SaaS，做二十年了，服務實體商家。他們十多年前就自家開發認證，各客戶分開登入、權限檢查寫在商業模組裡。當年很合理。

二十年後，他們想做個很小的改動：一個統一登入頁面，電郵作為用戶名。結果根本不是介面沒那麼簡單。那些檢查散落在數百個模組，統一登錄要動用戶模型、組織模型、憑證遷移、每個權限邊界。沒有人敢拍板，拖了好幾年。

當年那個登入頁，看起來像一個功能。留下的卻是整個身份模型。

業務推進時，自家認證往往就不夠用#

要公平點說，自家認證通常可以用很久。讓人登入、刷新會話，業務跑好多年。複雜度一點點疊加，總覺得「還掌握到」

但說「夠用」，很可能只是業務還沒撞牆。一旦撞上，問題通常不是認證本身，是旁邊的業務變了，「夠用」一夜間變成「礙事」。

下面這些情景，大部分產品擴展時都會遇到。看似不同，本質如出一轍：業務邁步了，老身份模型跟不上了。

企業客戶開始要求 SSO#

情境：客戶想用自己的 IdP 登入，但你的認證系統壓根沒有「外部身份供應商」這個概念。

第一單大企業合作到手，採購寄來需求文件。先是用 Microsoft Entra 或 Google Workspace SSO。然後兩者都要，因為下個客戶用別的。再來要 SCIM，自動建立和移除員工賬號。

每個客戶配置都不一樣：協議、欄位映射、證書輪換、組織架構的映射方式都不同。

而且這些工作沒啥能重複用。下個客戶帶著新 IdP、新配置，大多要重做。SSO 不是做一次就完的功能。簽下一個大客戶又重來，客戶數越多，成本只會更大。

這時認證再也不是「讓用戶登入你的產品」，而是「讓你的產品接入客戶的身份系統」。完全兩碼子事。

我們見過有公司全靠手動配置 SSO，全公司只有一個工程師搞得懂流程。他在，公司客戶上線。他休假，銷售和導入流程全卡。結果他離職，連知識都帶走了。

當初決定自家開發認證時，根本沒有這些問題。

產品需要統一分散的身份#

情境：一開始身份數據分散（按組織和產品分），業務做大你開始需要統一身份。

上面那家公司統一登入時就撞過這個，同一類情況在多產品線也常見。我們合作過一個平台，有 9 個產品（收購來的），各自帶一個認證/用戶資料庫。

收購無法自動合併認證。每收一個產品就是一套認證系統，9 個系統並行僅保養就消耗不少人力。

問題堆起來：A、B 兩產品同一個人算同一個用戶還是兩個？怎麼對齊同一個客戶組織？怎麼授權跨產品功能？員工離職時怎麼一次收回 9 個系統的存取？怎麼審計？

9 個認證本身都沒壞，加起來就是一堵牆。

「統一身份」聽起來就像個功能。實際上是要重定義基礎邏輯：怎麼算一個用戶、一個組織。幾乎每個功能都建在老的定義上，要改意味上層全要動。

AI 時代，代理人與 CLI 替用戶存取系統#

情境：登入的已經不只是人，還有 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、多組織、統一登入、代理存取。所以真正的分野不在功能表。

最容易忽略，但最值得比較的，是這幾點。全都聚焦一個重點：別好不容易逃出自家自寫的幾千行，卻又被另一套出不來的系統困死。

• 堅持標準協議，不要用某廠商自創技術堆疊。 OIDC、OAuth、RS256 簽發的 JWT，全都是你理解得了的東西。憑一般 token 內容看 claim，不用學專屬 API。
• 留隨時可出的門。 方案若是開源且能自管，就隨時可出（雖然要長期維護自管版也有隱形成本）。
• 帳單不能隨你用戶表成長。 按註冊/活躍用戶收費，最終停不上人數，進了一堆早已不登錄的人。規模大時變「增長稅」。上面會員組織會自建就是這定價推的。
• 你的數據不能被鎖死。 隨時能導出用戶數據。把這堆敏感數據放給專業服務商，也能免去本來你根本不該管理的風險。

公開聲明：Logto就是我們按這四點造的認證產品。它開源可自管，也有雲端託管版：要零維護用雲，要完全掌控可自管，而且隨時想遷出，門隨時打開。

標準 OIDC 下開箱即用支持登入、MFA、SSO、RBAC，帳單看 token 用多少，實際按需付費。

外面也有很多成熟方案，認證從沒唯一正確解。若你在評估，我寫過一篇如何選認證方案 詳談可參考。

總結：別把長期身份平台誤當一般功能#

第一天自家認證通常沒問題。問題是日後它會發展成底層基建。

業務每新增一步都得重檢視：企業要 SSO、安全要 MFA、產品想統一登入、多產品要連接、AI 代理要替用戶存取資源。這些小功能背後都藏著一連串策略，年年耗費原本該搞主線產品的工程成本。

這張賬單不會第一天就寄來。常常多年後才浮現。到那時你才恍然：當初寫的登入頁，其實已經是要伴隨產品一生的身份基礎設施。

認證多半不是你核心業務。看清這點越早，你就越能把人力、資源和精力集中在真正的主線產品。

常見疑問#

真的完全不能自己造認證？#

不是。早期 demo、內部工具、一次性驗證或極專用細緻權限分工，現成方案表達不了，都很合理。但要避免的是沒察覺地扛下長期的通用基建，讓它永遠待在公司日常維護範疇內。

認證（Authentication）和授權（Authorization）有何不同？#

認證回答「你是誰」。授權回答「你能做什麼」。在真 SaaS 裡兩者很難切割：用戶、組織、角色、權限、會話、token claim、審計紀錄全都交織。所以你換認證系統，不能只看登入頁。

為什麼企業 SSO 讓自家認證變複雜？#

因為這意味要讓你產品嵌入客戶自己的身份體系。不同客戶用不同 IdP、協議、claim 欄位、證書、組織對應法。接上第一個並不意味可複製。多半真的只有一人「手動」搞定。

我們自己跑了好幾年，還來得及遷移嗎？#

可以。只是一次性割接通常不是辦法。分層遷移：從新用戶、登入和企業 SSO 先導入身份平台，現有用戶下次登錄時再遷移。要從始到終都保留回滾方案和審計，不要讓遷移變不可逆。