為什麼你不應該自己打造認證系統：來自數十位客戶訪談的教訓

認證看起來像是你自己就能搞定的東西：電子郵件、密碼，加密，登入時比對。有多難？

你確實可以做得到。這就是陷阱所在。

我們跟數十個團隊聊過他們自家開發的認證系統。大多都因為同一個原因來找我們：它拖慢了業務。

不同行業、技術堆疊、規模各異，但結局都一樣。他們打造的認證變成了團隊肩上的技術債。

奇怪的是，這債務從不會以中斷運作的方式暴露出來。系統一年又一年地順利讓用戶登入，直到業務某個變化擋住了去路：安全審查、第一間企業級客戶、被併購，或者是一個橫跨兩個產品的新功能。

上週還「沒問題」。然後計畫表上的下一項就卡住了。

自己開發認證最大錯誤，就是當它是個功能來看。你可以第一天就寫出來。但當有真實流量跑進來後，它開始和你的用戶、組織、權限交織在一起。

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

登入頁的背後，其實是一整套身分模型#

所有自家開發認證系統最一開始都一樣：收電子郵件和密碼，加密後儲存，再在登入時比對。四十行代碼，乾淨又簡單。

麻煩從上線後開始。機器人狂刷註冊端點，你於是加上速率限制、CAPTCHA、裝置指紋辨識。某天早上簡訊驗證碼突然寄不出去，所以又拼上重試機制和每日上限。接著來的更難：安全的密碼重置、多因素驗證和它的復原流程、session 與刷新 token 、權限模型（遠遠不只是個 is_admin 布林值）。

單看每一項其實都不難。每個都能拆進一個迭代，但每做一個，你其實都是在代表產品回答一個更大的問題。

把那些答案疊加起來，你就得到了產品所默默預設正確的身分模型：誰算是一個用戶、同一個人能不能屬於多個組織、企業客戶自己的身分系統要怎麼接進來、有人離職時該怎麼撤回他的存取權。

你接下來寫的每個功能都把那些答案視為既定事實，而且系統經營越久要改動就越難。

我們在一家企業看到整個過程：垂直 B2B SaaS，經營二十年，服務於傳統店家營運。超過十年前就自家開認證系統，每個客戶一份登入與權限設定直接寫進商業模組。當時是個合理判斷。

二十年後，他們想做一個聽起來很小的需求：統一一個登入頁，用電子郵件作為使用者名稱。事實上一點也不是單純的頁面改版，這些邏輯已經蔓延進數百個模組，統一登入意味要動用戶模型、組織模型、憑證遷移、每一層權限邊界。沒人想背這個債案，最後拖了好幾年。

當年那個登入頁看起來是個小功能，實際留下來的是一整座身分模型。

當你的業務需要突破時，自家認證系統經常就變得不夠用了#

坦白說，自家認證大多數情況都可以跑很久。它能讓人登入、刷新 session、撐起你的日常營運好多年。複雜度是慢慢累積的，你也一直覺得自己控得住。

但「夠用」往往只是代表公司還沒撞牆。真的撞到時，問題通常也不是出在認證本身，而是旁邊的業務改變了，然後「夠用」一夜之間變成了「阻礙」。

下面這些情境，大多產品成長時都會遇到。表面看來形狀不同，本質都是一樣：業務往前推，舊的身分模型跟不上了。

企業客戶開始要求 SSO#

情境：客戶想用他們自己的 IdP 登入，而你的認證系統根本不懂「他人的身分提供者」這個概念。

第一筆企業訂單來了，採購寄來需求清單。首先要 SSO，指名他們的 Microsoft Entra 或 Google Workspace。然後是 SAML 加 OIDC，因為下一個客戶用別的系統。接著是 SCIM，自動開關用戶權限。

每家客戶的要求都不一樣：不同協定、欄位對應、憑證輪轉，還有怎麼把對方的組織映射到你的資料結構。

而且這些工程很少能直接重複用。下一個客戶又一個新 IdP，新設定，大多又要從頭開始。SSO 不是一次性的「功能」。每簽一個大客戶要再做一次，而且客戶越多成本越高。

認證已經不再是「讓用戶登入你的產品」。而是「讓你的產品接得上客戶的身分系統」。這是完全不同的兩份工作。

我們見過有公司 SSO 設定全靠手做，只有唯一一位工程師懂得全貌。他在時客戶就能上線，他休假時，銷售與上線流程都排隊卡關。他離職時，知識跟著人一起走。

這些問題當初決定自家開發時，根本沒想過。

產品需要統一零散的身分資料#

情境：你的身分資料起步時分散、按組織／產品區隔，但業務做大後你開始需要統一身分。

前面二十年老公司的例子就是這樣，他們想統一登入時撞到的問題，其他產品也經常遇到。我們合作過一個平台，有九個產品，全部都是併購來的，每個帶自己的認證結構與用戶池。

併購本身並不會「自動」合併身分啊。每收購一個產品你又多一份認證，九份並行需要實際多配人力去維護。

問題瘋狂累積：同一個人在 A、B 產品是同個 user 還是兩個？怎麼把同一個客戶組織對在一起？要怎麼授權跨產品功能？一個員工離開，要怎麼九個產品同時撤權？要查稽整個流程怎麼查？

九套系統其實都沒壞。綁在一起就變一道牆。

「統一身分」聽起來像功能，實際寫 code 是要重新定義最根本的事：什麼算是一個用戶、什麼算是一個組織。幾乎每個功能都寫在這之上，動這件事等於整個上層全動。

AI 時代，agent 和 CLI 也能代表用戶存取系統#

情境：不再只是人透過瀏覽器登入。現在 agent、指令列、腳本都聲稱要代表某用戶動作，而你的認證只懂一件事：一個人在頁面上登入。

一個 agent 需要幫用戶呼叫你的內部工具。MCP 伺服器必須安全對外資源。CLI 又需要存取帳戶資料，完全沒用瀏覽器。

三種情境考的問題其實一模一樣：這個請求代表哪個用戶、能碰哪些資源、這個 token 發給誰、作用範圍是什麼、要怎麼收回、紀錄應該記用戶還是 agent？

舊系統根本沒這些機制。MCP 需靠 OAuth 做授權。CLI 要嘛走 OAuth 登入，要嘛用能隨時撤換的 Personal Access Token 直接代表一個人。這些壓根不是登入頁設計出來的。

如果你的認證只設計給一個人在頁面登錄使用，現在就是要讓「不是人」的 client 也能代表這個人作業的時候了。

最大成本來自長期維護#

上述情境沒有任何一項是「認證 crash」。系統繼續運行。每項看來只是個功能，實際開始動手就變成產品策略、資料搬遷、客戶交付大工程。

MFA 最明顯。表面是「登入後再驗一次」而已。

兩步之後：哪些組織和用戶強制啟用、管理員可否強制啟用、改付款資料或匯出時要不要再驗一次、怎麼產生和重置復原碼、客服可不可以幫忙重設、SSO 用戶的 MFA 算你的還是客戶的 IdP？加 MFA 基本就是加上一層全新的安全政策。

「同步用戶」也是一樣：背後牽涉新聘用戶、離職流程、跨組織成員，每個動作都假設你的 user 和 org 模型一開始就設計正確。

功能疊加越多，你越是在自己產品內養一個身分認證產品。第一版很便宜，幾個工程師花幾週寫出來。但這東西年年都要餵食維護下去。

隱藏的真相：那份賬單只是換了付款方式#

自己做的最常見原因就是為了省錢，這並不是天真。

我們訪問過一家會員組織，五年前徹底算過。他們總會員人數約十萬，卻只有幾千人會常態登入。坊間收費都按總用戶數開，報價直接超預算，自行開發看起來便宜多了。那一年，這決定沒錯。

五年後，局勢逆轉了。光是維護自己的登入、確保安全，實際早已超過買 off-the-shelf 方案。

第一年，你省下來的發票看得見，工程工時感覺不重。第五年，省下的錢沒變，工程工時卻變成 roadmap 延宕、安全債、沒人想接手的維運。

所以自家認證不是免費。從來就沒有哪張「認證訂閱收據」。帳單藏在人月、延誤、重工、安全債、還有你本該放在核心產品上的工程心力中。

關鍵知識落在少數工程師身上#

那個手動維運 SSO 的工程師不是特例。自家維持認證系統久了後，所有關鍵知識都會積在一、兩個人身上：哪個客戶用什麼設定、哪些欄位不能動、某次搬遷為什麼這樣做。通常沒寫進文件，全部只能靠口述或腦袋記。

他在時項目推得進。沒人在時，企業銷售 pipeline 就卡住。你會發現最重要的基礎設施根本沒 owner，只有「唯一知道的人」。

也有團隊把自家 SSO 給客戶做成真正的自助上線平台。看似很成熟，但問細一點就知道只服務十來個客戶。也見過月活百五萬用戶的產品，花大錢維護整套系統，卻只有十幾個客戶用到。

你以為自己在做一個功能，其實在開發一套內部產品，用戶分攤下來成本極高。若你本來就是做身分管理的，當然值得。如果不是，這就是最純粹的隱形帳單。

你想讓工程師在哪裡發揮價值？#

回到那家二十年 SaaS。他們可不是不會寫 code，要能讓同一行業的產品二十年不死，絕對懂客戶。

這就是整個問題。講白了：你想讓他們一個個手調客戶 SSO、從數百個模組裡拔出二十年權限邏輯，還是再鑽深一點做更厲害的行業產品？

這和寫程式的完美主義無關，而是資源配置。你要做 bill pay、垂直 SaaS、會員入口、營運軟體，沒客戶會因你自家寫 OAuth server 而多幫你多付一塊錢。

有個 bill-pay 團隊很直白：我們的內部 IdP 夠用，但這是策略決定。認證別寫太多，一切經歷留給 bill pay 本業，認證用現成最穩的就好。

認證必須要可靠。但「可靠」不是「非得自己寫」。你的資料庫、email 發送、cloud 都要可靠，成熟團隊不會只因東西很重要就自動判斷要自家持有。

對大多產品來說，認證是核心依賴，卻不是核心差異。只要身分不是你的本業，自己產品內養認證長期來說多是資源消耗戰，不是護城河。

什麼時候自己做認證還是合理的？#

很容易直接走極端：「一行認證代碼都別自己寫」。其實也不對。

有幾個情境自家做（或做一半）完全合理：內部 demo、很早期原型、一次性驗證專案。而且，如果你的業務有很特殊、細緻的授權需求（市面解決方案真的沒法 cover），自己留那一段、讓外部平台搞驗證、session、SSO、MFA、用戶目錄，會是很合理的解法。

只是要小心「原型下坡」。我們常見到這流程：兩位開發者花六到八個月 prototype，把外部系統整合進來。出發點很好，產品也確實不差，只是本來根本沒打算給全公司規模用。

而原型最容易變成長期架構。半年後它變成「現行方案」，兩年後叫「舊系統」，五年後等於「不能碰的基礎建設」。自己動手做認證，要離開的最佳時機通常不是出錯以後，而是在它蠶食成基石之前。

所以，關鍵判斷是這：不是你有沒有寫認證的 code，而是你有沒有在不自覺情況下扛下一份「通用型」身分基礎設施，然後自己養下去。

真正的邊緣功能自己做，中軸的身分層要很小心。千萬別一不小心蓋出一座 CIAM 平台。

不自己做要怎麼選擇認證方案？#

你決定不自己寫，下一題接著來：要買誰的方案？怎麼選？

成熟方案該有的功能其實都有： SSO、MFA、多組織、統一登入、agent 存取。所以重點往往不在功能表，而是一些容易忽略但超級重要的細節：

• 堅持標準協議，不要用某家廠商自創的東西。 OIDC、OAuth、RS256 簽名 JWT 這你都看得懂。你自己就能直接從標準 token 讀 claim，不用學專屬 API。
• 要有出口，方便隨時離開。 方案是開源且可以自架的，你想走就走。（但長期自維又有另一份隱形成本。）
• 計價不要跟著 user table 成長。 按註冊用戶或月活課金的話，你的資料表只會膨脹、充滿從沒再登入的人，大規模就變成「成長稅」。這正是上面那組織最後得自己開發的主因。
• 你的資料要能自由匯出。 什麼時候都能自己拉資料。敏感用戶交給專業主機托管，也少背一堆本不該自己直接保管的個資風險。

全透明揭露：Logto 就是我們基於這四點做的產品，也是開源、自架、也有雲端託管 Cloud 版本：Cloud 省掉自管，全開源可自己掌控，不想用了門隨時開。

註冊、MFA、SSO、RBAC 都用標準 OIDC 開箱即用，計價是按 token 算，等於你用多少付多少。

市面上還有別的成熟選項，認證也從來不是只有唯一答案。如果你正在評估，我另外寫過一份怎麼選擇身分認證方案。

結論：不要把長期身分平台當成一個普通功能#

Day1 你自己做認證系統通常沒問題。問題在於，未來它會成為你的基礎建設。

每一步業務推進它就再度冒出來：企業要 SSO、安全要 MFA、產品要統一登入、多產品間要連通、AI agent 要代表用戶存取資源。每個小 feature 背後全是政策玩法，而長久維護下去實際消耗掉你本該投資在主產品上的工程時光。

這筆帳單 day1 絕不來，通常好幾年後才浮現。到那時你終於會明白：當年那個登入頁，其實早就是會一路撐起你整個產品生命週期的身分基礎設施。

認證可能不是你的本業。越早看清，越早能把心力投入到你真正想做的那個產品上。

FAQ#

你是不是真的一行認證都不要自己寫？#

不是。前期 demo、內部工具、一次性驗證專案、或是極細緻授權需求（現成方案完全做不到）都可能適合自己開發。要避免的是一不小心扛下跨年甚至跨代維護的「通用型」身分基礎設施，把它綁死在你的實際產品維運流程裡。

認證（Authentication）和授權（Authorization）差在哪裡？#

認證回答「你是誰」。授權回答「你能做什麼」。實際 SaaS 中兩者很難拆開：用戶、組織、角色、權限、session、token claim、稽核紀錄全都交織一起。所以換認證方案時，不能只看登入頁。

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

因為那代表你的產品要能直接接上客戶自己選用的身分系統。不同客戶用不同 IdP、協議、claim 欄位、憑證、組織對應。第一位客戶能連上不代表之後都能照抄，經常變成只剩唯一一人懂的手工作業。

我們用了自家系統好多年，還能遷移嗎？#

可以，但不要硬切一刀，建議分層過渡。先把新註冊、登入、企業 SSO 全放到新的身分平台，既有用戶等他們下次登入時再遷移。全程保留 rollback 和稽核記錄，遷移過程才不會變成不可逆。