多產品共用會員:單一登入(SSO)的架構思考

第一個產品做會員系統的時候,大家都很直覺:註冊、登入、忘記密碼,做在自己的資料庫裡,兩週搞定。問題會在你開第二個產品時爆開——新產品又做了一套會員,兩邊的使用者對不起來,同一個人有兩個帳號、兩組密碼,行銷想發個通知,先問工程師「這兩批名單怎麼合」。我們自己就是這樣走過來的:團隊底下有官網商城、也有多個 App 產品,曾經每個產品各養一套會員,後來痛定思痛,把身份抽出來做成集團會員中心,讓所有產品走單一登入(SSO,Single Sign-On,一組帳號登入所有服務)。

這篇分享我們實戰下來的三個關鍵架構決策。如果你的公司有一個以上的數位產品,或未來打算有,這些坑建議在動手前就想清楚。

決策一:單一身份源 —— 會員資料只有一個「真相」

核心原則一句話:全集團只有一個地方可以「擁有」會員。我們把它叫身份中心,使用者的註冊、登入、改密碼、第三方登入綁定,全部只發生在這裡。各產品自己的資料庫不再有「會員表」,只有一張輕量的鏡像表,存身份中心發的識別碼加上顯示用的暱稱,讓產品端的訂單、紀錄有東西可以關聯。

為什麼不讓各產品各存一份完整會員資料、再互相同步?因為雙向同步是分散式系統裡最難搞的題目之一:兩邊都能改,就一定會衝突,衝突就要仲裁,仲裁規則就會有例外,最後你會養出一個沒人敢動的同步程式。單一身份源把問題砍掉——只有一個地方能寫,其他地方都是唯讀的鏡像,架構立刻簡單一個量級。

決策二:資料最小化 —— 產品端不碰個資

第二個決策比較反直覺:各產品的資料庫禁止儲存 email、電話、地址、密碼雜湊這些個資。需要顯示會員資料時,透過 API 即時向身份中心取,用完不落地。

這樣做有兩個好處。資安上,個資只集中在一個系統,防護資源可以集中投放;哪天某個邊緣產品被打穿,外洩的只有識別碼和暱稱,不是全集團的電話地址。法遵上,個資保護法規要求你交代個資存在哪、誰能存取,個資散落十個資料庫跟集中一處,回答這題的成本差非常多。代價是產品端偶爾要多打一次 API,但這個代價遠小於「每個產品都是一個潛在外洩點」。

會員資料像現金:集中放在保險箱,好過每個抽屜都塞一點。抽屜越多,你越說不清楚錢在哪裡。

決策三:同步機制 —— outbox 加 webhook,不做即時強一致

身份中心的資料變了(例如使用者改了暱稱),各產品的鏡像要跟上。我們的做法是 outbox + webhook:身份中心每次異動,先在自己的資料庫同一筆交易裡寫一筆「待發事件」(outbox,發件匣),再由背景程序把事件透過 webhook(系統對系統的主動通知)推給各產品;產品端收到就更新鏡像,萬一漏接,還有「用到時發現資料太舊就即時回查」的補償機制。

為什麼不追求即時強一致?因為暱稱晚幾秒同步到另一個產品,商業上完全無感;但為了「絕對即時」把多個系統綁進同一個交易,任何一個產品掛掉都會拖垮登入,得不償失。先想清楚哪些資料可以容忍延遲,是分散式架構最省錢的一題。身份驗證本身(登入發的 token)是即時的,個資查詢是即時的,只有顯示用的鏡像欄位走非同步——分層對待,系統才會又穩又便宜。

帳號合併:遲早要面對的髒活

最後提醒一個大家都會拖到不能再拖的題目:帳號合併。只要你同時開放 email 註冊和第三方登入(Google、Apple、LINE),就一定會出現同一個人有兩個帳號的情況。合併不只是併兩筆會員資料——兩邊產品的訂單、點數、紀錄要跟著搬,搬完舊識別碼還要留轉址對應,不然歷史連結全斷。我們的建議是:在身份中心的第一版就把「合併」設計成一級功能,寧可先做粗糙的人工審核版,也不要假裝這件事不存在。

會員中心是那種「做對了沒人稱讚、做錯了天天救火」的基礎建設。如果你正要開第二個產品,或已經被多套會員系統搞得很痛,歡迎跟我們聊聊,我們可以把自己走過的路直接攤給你看;也可以先參考客製化系統與 SaaS 服務,了解我們怎麼協助企業把這類共用基礎設施建起來。如果你同時在煩惱 App 端的架構,一套程式碼上架雙平台的 Capacitor 實戰那篇也值得一讀。