企業單一登入 SSO 完整指南：SAML、OAuth、OIDC 差在哪？老闆與 IT 採購搞懂帳號治理、離職撤權與資安合規

企業單一登入 SSO 是什麼？一句話結論

單一登入（SSO, Single Sign-On）是讓員工用「一組帳號密碼」登入公司所有系統的機制——登入一次，ERP、CRM、Email、人資系統、各種 SaaS 全部通行，不用每個系統各記一組密碼。對中小企業老闆來說，SSO 真正的價值不在方便，而在「帳號治理」：員工到職一鍵開通所有權限，離職一鍵全部關閉，再也不會有「離職三個月帳號還能登入」這種破口。

這篇文章寫給正在評估要不要導入 SSO、或在跟外包廠商談系統時想搞懂帳號架構的老闆與 IT 採購。不需要懂技術細節，但讀完你會知道 SAML、OAuth、OIDC 差在哪，自建還是買現成的怎麼選，以及導入時哪些地方最容易踩雷。

為什麼帳號散落是中小企業最被低估的資安漏洞

一間 30 人的公司，員工日常要登入的系統可能有 15-20 個：Email、雲端硬碟、ERP、CRM、客服系統、設計工具、財會軟體、各種 SaaS。沒有 SSO 的話，每個人要記十幾組密碼。結果是什麼？大家用同一組密碼到處註冊、把密碼寫在便利貼、設成「公司名稱 + 123」。

這帶來兩個直接風險。第一，只要一個系統外洩，駭客拿同一組密碼去撞其他系統（credential stuffing），整間公司全破。資安調查機構 Verizon 在 年度資料外洩調查報告（DBIR） 中長年指出，「被盜用的帳密」是企業入侵事件中佔比最高的單一原因。第二，帳號散落讓「離職撤權」幾乎不可能做乾淨——IT 根本不知道一個員工到底開了哪些系統的帳號。

這正是 SSO 要解決的核心問題：把「身分」這件事集中管理。員工的身分由一個中央系統（身分提供者，IdP）統一掌管，所有應用系統都信任這個中央系統。開帳號、關帳號、改權限，全部在一個地方完成。

SAML、OAuth 2.0、OIDC 差在哪？老闆版白話對照

評估 SSO 時一定會撞到這三個縮寫，廠商簡報也常拿它們唬人。其實用一句話就能分清楚：SAML 和 OIDC 是「證明你是誰」（驗證身分），OAuth 是「授權你能拿什麼」（授權存取）。

對中小企業的實務建議：如果你要串的是現代的 Web 應用或自家客製系統，優先選 OIDC，它輕量、對行動裝置友善、生態最活躍。如果你要整合的是傳統企業軟體或某些只支援 SAML 的老 SaaS，那就走 SAML。多數成熟的身分平台（IdP）兩種都支援，所以這個選擇通常由「你要串的系統支援哪一種」決定，而不是反過來。

導入 SSO 帶來的 4 個立即效益

• 到職/離職一鍵搞定：新人報到當天，從中央系統一次開通所有該有的權限；離職當天一鍵全關，不再有殭屍帳號。
• 資安大幅提升：一組強密碼 + 多因素驗證（MFA）保護所有系統，取代「十幾組弱密碼」。撞庫攻擊基本失效。
• 稽核變簡單：誰有哪些系統的權限、誰在什麼時候登入過，全部在一個後台看得到，做 ISO 27001 或個資法稽核時省下大量時間。
• 員工體驗變好：少記十幾組密碼、少打十幾次登入，IT 也少接「我密碼忘了」的求救電話（這類工單常佔 IT 客服一大半）。

離職員工帳號沒撤，是最常見的內鬼破口

先說一個真實的場景模式：業務主管離職，跳槽到競爭對手，三個月後公司發現客戶名單外流。一查才知道，他離職時 IT 只關了 Email 和 ERP，但 CRM、雲端硬碟、某個報表系統的帳號都還活著——因為這些是他自己當年註冊的，IT 根本不知道存在。

這類事件的根因都是同一個：沒有集中的身分管理，「離職撤權」只能靠 IT 憑記憶一個一個關，一定會漏。導入 SSO 後，員工的所有系統存取都掛在中央身分上，HR 在系統裡把這個人標記為離職，所有權限同步失效，幾秒鐘的事。

這也跟「員工日常用工具會不會洩密」是同一條治理線。如果你正在補這塊，可以一起看 員工日常用 AI 不洩密完整 SOP，身分治理（誰能進）和資料治理（進去能做什麼）要搭配著做。

自建 SSO vs 採購身分平台（Okta、Entra ID、Google）

給中小企業的務實建議：如果你已經在用 Microsoft 365，Entra ID 內建的 SSO 通常是最低摩擦的起點，幾乎不用另外付費就能把常用 SaaS 串起來。如果你是 Google Workspace 體系，Google 的 SSO 同理。只有在「需要高度客製、或要把員工身分和產品會員身分整合進自家系統」時，才值得考慮自建——而那通常是一個完整的開發專案了。

自家做身分中樞是什麼樣子？我們做過的 恆遠會員中樞系統 就是把分散在多個產品的會員身分集中成單一登入與權限來源；同樣的設計思路也用在 AI 智慧客服系統 的後台權限上。如果你的需求接近這類「身分要跨系統打通」，可以參考 客製化 SaaS 軟體開發完整指南 了解開發層面的考量。

導入 SSO 的 6 個步驟

實務上最容易被跳過、卻最重要的是第五步「角色與權限模型」。很多公司把 SSO 當成「登入入口」就上線了，沒設計好「誰能存取什麼」，結果變成「一組帳號能進所有系統」——方便是方便，但一個帳號被盜，全公司資料外洩。正確做法是按角色（業務、會計、行政、主管）設計最小權限，SSO 只是讓這套權限好管理的工具。

SSO 常見的 5 個迷思與地雷

• 迷思一：「SSO = 不安全，一把鑰匙開所有門」。剛好相反，SSO 搭配 MFA 比「十幾組弱密碼」安全得多。重點是那把鑰匙要夠強（強密碼 + MFA + 異常登入偵測）。
• 地雷二：沒設計權限模型就上線。SSO 解決「登入」，不解決「授權」。一定要搭配角色權限設計，否則只是把風險集中。
• 地雷三：把 IdP 本身當單點故障。如果身分平台掛了，全公司都登不進去。採購雲端 IdP 要看它的可用性 SLA；自建則要做高可用。
• 地雷四：忘了非員工身分。約聘、外包、供應商、客戶也需要存取部分系統，這些「外部身分」要納入規劃，不能只想員工。
• 地雷五：低估教育訓練。員工習慣了各系統各登入，突然改用 SSO + MFA 會抱怨。上線前的溝通與教學做足，導入才順。

找外包做系統時，SSO 與帳號治理要問的 6 件事

如果你想把公司帳號治理一次理清

帳號與權限這件事，平常亂一點不會出事，一旦有人離職帶走資料、或某個系統被撞庫攻破，代價就是客戶名單、商業機密、甚至個資外洩的法律責任。SSO 是把這件事從「靠 IT 記得」變成「系統自動管」的關鍵基礎建設。

如果你不確定自己公司現在有多少散落帳號、離職撤權做得乾不乾淨，建議先做一次盤點。需要專業團隊幫你規劃身分架構、或把 SSO 整合進自家系統，可以參考 客製化網站 & 系統開發服務，或透過 AI 顧問服務 先聊聊現況與優先順序。

結語：先管好「誰能進」，再談「進去能做什麼」

資安有很多層，但身分是第一道，也是最常破的一道。多數中小企業的資安事故真正的破口在一組弱密碼、一個沒撤掉的離職帳號，而非被高深的駭客技術攻破。SSO 把「身分」這件事從散落各處收攏成一個可管、可稽核、可一鍵撤權的中心，這是投報率很高的基礎建設。

今天可以先做一件事：請 IT 列出「過去一年離職的員工，帳號是否都已全部關閉」。如果這份清單列不出來、或有疑慮，那就是你公司該認真看待 SSO 與帳號治理的明確訊號。