第三方登入與 SSO 指南：LINE、Google 登入怎麼串
登入頁上多一顆「使用 LINE 登入」的按鈕，看起來是個小功能。但它一旦按下去，你的會員資料從哪裡來、顧客換裝置怎麼進得來、客服遇到「我登不進去」要怎麼查，全部都會跟著改變。
第三方登入不是視覺上的加分項，而是會員架構的一部分。這篇用非工程師聽得懂的方式，說明它解決什麼問題、要付出什麼代價，以及哪些地方不先想清楚會在上線後變成長期客服負擔。
第三方登入到底解決了什麼
第三方登入指的是讓使用者用既有的外部帳號（例如通訊軟體、搜尋服務或手機系統提供的帳號）進入你的網站或 App，不必另外設定一組帳號密碼。它真正處理的是三個痛點：
註冊過程的摩擦。每多一個欄位、每多一次驗證信，就多一個放棄的理由，行動裝置上打字尤其麻煩。少一道關卡，就少一批在半路離開的人。
密碼相關的客服。忘記密碼、重設信沒收到、驗證碼過期，這些訊息會穩定佔用客服時間，而且完全不產生價值。把密碼交給外部平台管理，這類問題會明顯減少。
資料正確性。使用者自己打的電子郵件可能打錯，由平台回傳的資料至少是經過對方驗證的帳號。
要注意的是：它換來的方便，代價是你把登入這件事的一部分主控權交給了外部平台。這不是不能接受，但要知道自己接受了什麼。
常見選項怎麼判斷該支援哪幾種
台灣常見的選項包含通訊軟體帳號、搜尋服務帳號、手機作業系統帳號與社群平台帳號。與其比較哪一家比較好，不如用下列問題判斷：
- 你的顧客本來就在哪裡？ 如果你的顧客經營與客服主要透過通訊軟體，那條路線的登入通常最順，也最容易與後續的推播和會員綁定串在一起
- 你的 App 上架在哪些平台？ 部分行動平台對「提供了第三方登入的 App」有額外的規範要求，送審前必須確認該平台的最新審核說明
- 你需要哪些資料？ 不同平台開放的欄位不同，先確認你真正需要的資料拿不拿得到
- 維護成本你吃得下幾種？ 每一種登入方式都是一條要長期維護的路徑，平台規格更新時都要跟著調整
一個常見的錯誤是「先全部都做」。每多一種登入方式，要測試的組合與客服要處理的情境就跟著變多，建議第一版只做最貼近你顧客習慣的一到兩種，之後再依實際使用狀況擴充。這種先驗證再擴充的思路，和MVP 最小可行產品開發指南提到的原則是一致的。
與自建帳號並存：資料結構決定一切
多數品牌的錯誤不在於選了哪個平台，而在於把「登入方式」和「會員身分」混為一談。
正確的心智模型是：會員是一個人，登入方式是他進門的鑰匙，一個人可以有很多把鑰匙。 資料結構上，會員資料與登入憑證應該分開存放，一筆會員可以對應多筆登入方式。
這樣設計之後，下列情境才有解：
| 情境 | 有分開存放 | 沒有分開存放 |
|---|---|---|
| 顧客今天用通訊軟體、明天用電子郵件登入 | 認得出是同一人 | 變成兩個帳號，點數與訂單斷開 |
| 顧客換手機、原帳號無法使用 | 可用另一把鑰匙進入 | 只能重新註冊 |
| 日後要新增一種登入方式 | 新增一種鑰匙即可 | 需要改動核心會員邏輯 |
如果你已經有會員系統要加上第三方登入，這一段是整個專案最需要謹慎的地方，相關的會員資料設計可以參考會員系統與 CRM 開發指南。
資料取得範圍與同意
第三方登入的流程中，使用者會看到一個授權畫面，說明你要求存取哪些資料。這裡有兩個原則：
只要必要的範圍。要求的權限越多，使用者在授權畫面上猶豫的機會越大，你需要承擔的資料保護責任也越大。能不要就不要。
登入的同意不等於行銷的同意。使用者同意用該帳號登入，不代表同意接收行銷訊息或被用於其他目的。這兩件事應該分開詢問，並留下同意的時間與版本紀錄。蒐集目的、保存期間與使用者權利該怎麼交代，可以看網站隱私權政策與個資法指南。
另外提醒：分析工具裡不應該出現可直接識別個人的資料，第三方登入回傳的識別碼與電子郵件也一樣，相關做法見GA4 導入指南。
帳號合併與找回：最容易出事的地方
上線後最常見的客訴是「我以前買過，怎麼現在訂單都不見了」。原因幾乎都是同一個人被系統認成了兩個會員。
設計時至少要決定這幾條規則：
- 如果新的登入方式帶來的電子郵件與既有會員相同，要不要自動合併？ 自動合併方便，但有被冒用的風險，較安全的作法是要求額外的身分驗證後才合併
- 合併之後點數、優惠券、訂單怎麼處理？ 這是商業規則，不是工程問題，要由業務端拍板
- 能不能解除綁定？ 若允許，必須確保解除後使用者仍有其他方式進得來，否則等於把人鎖在門外
- 客服介入的流程長什麼樣？ 要有明確步驟與紀錄，而不是靠個別客服臨場判斷
與帳號安全相關的其他基本功，例如登入嘗試的限制、異常登入的處理與日誌保存，可以參考企業網站資安基本功。
SSO 是什麼：用白話解釋企業內部的單一登入
**SSO（Single Sign-On，單一登入）**指的是員工登入一次公司帳號之後，就能進入多套內部系統，不必每一套都記一組帳密。概念和消費端的第三方登入相似，但目的不同：消費端在意的是降低註冊摩擦，企業端在意的是權限管理與離職控管。
對中小企業而言，SSO 最實際的價值有兩個：人員異動時可以一次關掉所有系統的存取權，以及權限可以集中檢視。當你的內部系統累積到一定數量，員工開始用便利貼記帳密、離職後帳號沒人記得關，就是該評估的時機。相關的內部系統規劃可參考內部後台系統開發指南。
導入 SSO 通常不是從零做一套，而是選擇成熟的身分服務，再把既有系統逐一接上去。可行性的關鍵在於你的現有系統能不能被改造，這需要先做架構評估。
導入前的檢查清單
- 顧客主要使用的平台是哪一個，第一版只做最必要的
- 會員資料與登入憑證分開存放，允許一人多種登入方式
- 授權範圍只要必要欄位，其餘登入後另外詢問
- 登入同意與行銷同意分開，並保留紀錄
- 帳號合併規則、解除綁定規則、客服找回流程都先定好
- 若有 App，確認上架平台對登入方式的最新審核要求
- 測試涵蓋新註冊、既有會員綁定、換裝置、解除授權、平台回傳失敗等情境
- 平台若停止服務或變更規格，你有沒有讓既有會員改用其他方式登入的備案
第三方登入的價值是把「進門」這件事變簡單，但前提是你的會員架構撐得住一個人有很多把鑰匙。架構對了，日後加任何一種登入方式都只是加一把鑰匙；架構錯了，每加一種都在製造重複會員。
如果你正在評估要不要加上第三方登入，或現有會員資料已經出現重複帳號的問題，與 NETVANA 討論你的會員與登入架構。NETVANA 的顧問服務包含技術架構審查，開發專案以兩週為一個 Sprint、每個週期結束提供可操作的 Demo，實際流程可以看軟體開發流程。
延伸閱讀：會員資料該怎麼設計，可以看會員系統與 CRM 開發指南；登入後要把服務接到通訊軟體上，可以看LINE 機器人開發指南；帳號安全與事故處理，可以看企業網站資安基本功；蒐集個資要怎麼告知，可以看網站隱私權政策與個資法指南；第一版該做到哪裡，可以看MVP 最小可行產品開發指南。
