在公司大樓的大門刷一次門禁卡，電梯、樓層玻璃門、會議室就一路放行，沒有人會要求你每進一道門都重新掏一次證件。SSO（Single Sign-On，單一登入）做的是同樣的事，只是把門換成 Slack、Notion、Google 文件和各種後台，讓你登入一次，就能進入多個彼此信任的服務。
不過這把「一次通行」的鑰匙有兩面。每個工具各登入一次的時候，密碼多、入口多，離職交接時也容易漏掉幾個沒人記得的帳號；改成單一登入之後，這些麻煩確實會變少，但登入那一步一旦被攻破，影響的範圍也跟著放大。對設計師、中小企業主和網站經營者來說，更實際的問題是 SSO 在什麼規模下才值得導入、風險出在哪裡、動手之前該先把哪幾件事做好。
要回答這些，得先把單一登入跟幾個常被混為一談的東西分清楚。
SSO 是什麼？
SSO 指的是登入一次，就能進入多個彼此信任的服務，不必每個服務各登入一次。美國國家標準與技術研究院（NIST）的 SP 800-63C 把這種做法歸在「聯合身分」（federation）之下，由身分提供者（Identity Provider，IdP）驗證使用者，再把一份簽章過的斷言（assertion，證明「這個人已通過驗證」的電子文件）交給提供服務的一方，也就是依賴方（Relying Party，RP）。依賴方不必自己驗證使用者的驗證器（密碼、驗證碼 App、安全金鑰這類用來證明身分的東西），使用者也就不必在每個服務各持有、各維護一組獨立的驗證器。中文裡的單一登入，說的就是這件事。
這個定義很容易跟三件事混在一起。第一，SSO 不是「所有服務共用同一組帳密」。共用密碼是每個服務各存一份、各驗一次。AWS 的說明把「用同一組憑證、在每個服務各登入一次」的做法稱為 Same Sign-On，它會把憑證（帳號密碼這類登入資料）存在使用者的裝置上並同步，但每次登入仍得用同一組憑證重走一次登入流程；單一登入則是驗證一次之後，就不必再驗。
第二，SSO 也不是密碼管理員。密碼管理員是幫你把密碼自動填進各個登入頁，登入這件事還是每個服務各做一遍；單一登入則是把登入那一步集中交給一個可信的來源，各服務手上沒有你的密碼。第三，SSO 不等於多重要素驗證（MFA，密碼之外再多驗一道，例如手機上的驗證碼）。依 AWS 的說明，MFA 提供的是額外的安全防護層，降低憑證被偷之後遭冒用的機會，兩者可以整合使用。
換句話說，SSO 只解決「登入一次」這件事，不保證那一次登入夠安全，這要看身分提供者那一端怎麼把關。
日常最常遇到的兩種單一登入場景
多數人其實每天都在用 SSO，只是不一定叫得出名字。兩種場景的底層邏輯一樣，都是把登入那一步交給別人驗證，差別在於那個帳號歸誰管；這個分別，會一路影響後面談到的好處、風險和導入方式。
用 Google、Apple、Microsoft 帳號登入其他網站
最熟悉的版本，是網站或 App 上的「使用 Google 登入」、「使用 Apple 登入」按鈕。畫面上看起來只是按一下就進去，背後則是網站（依賴方）把驗證工作交給 Google 或 Apple（身分提供者）。Google 的 OpenID Connect 文件說明，流程是網站把使用者導向 Google 的授權端點（Google 負責處理登入同意的網址），使用者同意之後，網站的後端再用授權碼向 Google 換回 ID 權杖，也就是一份簽章過的證明。網站拿到的是「這個人通過驗證了」的證明，以及使用者同意分享的姓名、信箱，拿不到密碼。
Apple 這條路還有兩個特色。Apple 的 Sign in with Apple 白皮書說明，使用這項服務的 Apple 帳號必須開啟雙重驗證；使用者也可以選「隱藏我的電子郵件」，網站收到的就不是真實信箱，而是 Apple 產生的私密轉寄地址。每個轉寄地址對使用者與開發者都是唯一的，不能拿來跨 App 追蹤，也無法拿來比對綁在個人信箱上的其他個人資料。用 Microsoft 帳號登入也是同類做法。這類登入是個人帳號的 SSO，帳號歸使用者自己管，離開那個網站也帶得走。
用公司帳號一次登入多個工作工具
組織版本是另一種畫面：員工用公司帳號登入一次，再開 Slack、Notion、Google 文件或後台系統，都不必重新輸入。Microsoft Learn 的說明是，使用者用一組憑證登入之後，可以開啟所有被指派給他的應用程式，不必再登入；員工則透過類似 My Apps 的入口頁，找到被指派的工具。
這個版本的主角不是員工，而是公司裡掌握身分提供者的管理者。管理者決定誰能進、進哪些工具、要通過哪些驗證，人員離職時也從同一處收回。以設計工作室或十幾人的小公司來說，一份員工名單，就同時管著十幾個工具的門。公司若用 Google Workspace，管理者可以在管理控制台把工作工具加成 SAML 應用程式，讓員工用公司管理的 Google 帳號登入，再依機構單位或群組決定誰能用。
兩種場景的差別在於帳號由個人還是公司掌控
兩個場景可以收成一個判準來看。社群帳號登入追求的是註冊與登入的門檻低，帳號是使用者自己的，離開網站也帶得走；公司帳號 SSO 追求的是管理者管得住，人離開公司，帳號和所有工具的權限一起被收回。
這個分別是通則，不是哪家廠商的結論，但很好用。往後遇到任何一個「使用某某帳號登入」的畫面，先問一句這個帳號是誰在管。答案是使用者自己，重點就在降低門檻；答案是公司，重點就在集中管控。
SSO 靠身分提供者與服務提供者之間的信任運作
整套機制的運作方式，很像機場的安檢與登機門。安檢人員驗過你的護照之後，發給你一張登機證；各個登機門不必再自己查護照，只認這張登機證是不是真的。單一登入的結構也一樣，是兩個角色加一份證明。
身分提供者負責驗證你是誰；服務提供者（Service Provider，SP，也就是你要進的那個工具或網站，NIST 稱為依賴方）只信任身分提供者簽發的證明，而且兩者事先已建立信任，服務提供者認得身分提供者的簽章。NIST SP 800-63C 的描述是，身分提供者是帳號與依賴方之間的橋樑，它與使用者完成一次驗證，再建立斷言來代表這次驗證；依賴方處理並驗證了有效的斷言，才會建立已驗證的工作階段（也就是「已登入」的狀態）。
一次登入的流程和第二個工具不必再輸入的原因
打開某個工具時，工具發現你還沒登入，就把你導向身分提供者；你在那裡輸入帳密（有設定的話還有 MFA）；身分提供者簽發憑證，把你導回工具；工具驗證憑證，放你進去。各家文件的切法略有不同，但這幾個動作的骨架一樣，Microsoft Learn 也強調這整個過程是自動發生的，應用程式不直接管理使用者的憑證。
第二個工具為什麼不用再輸入？因為登入狀態是存在身分提供者那一端。你打開第二個工具時，它同樣把你導向身分提供者，但身分提供者已經知道你登入過，會直接簽發新的憑證，不再要求你輸入。AWS 的說明也提到，使用者先前若已通過驗證，單一登入服務會直接回覆確認，使用者不必再輸入。
登出則要另外設計，在一個工具登出，不代表其他工具也跟著登出。OWASP 的 SAML Security Cheat Sheet 就提醒，要事先訂好 SAML 登出與工作階段管理的準則。單一登出是獨立的議題，不是裝了 SSO 就自動有的功能。
SAML 與 OIDC 是目前最常見的兩套協定
身分提供者與服務提供者要用同一種「語言」交換證明，最常見的是 SAML 與 OIDC（OpenID Connect）。購買工具或設定時，常會在畫面上看到這兩個詞。Microsoft Learn 的描述是，SAML 2.0 是廣泛用於企業、以 XML 為基礎的成熟標準，適合傳統網頁應用與需要詳細使用者屬性的情境；OIDC 則是建立在 OAuth 2.0 之上、使用 JSON 格式權杖的現代協定，適合現代網頁應用與手機 App。對開發者來說，OIDC 通常比較容易整合，SAML 的優勢是企業相容性較廣。
OAuth 本身處理的是「授權」，也就是允許某個 App 存取你的資料；OIDC 是疊在它上面、確認「你是誰」的「驗證」那一層。OpenID Foundation 的說明是，OIDC 是建立在 OAuth 2.0 之上、可互通的驗證協定，ID 權杖至少會包含使用者識別碼，以及使用者何時、如何驗證的資訊。Google 的文件也說明，它的 OAuth 2.0 API 符合 OpenID Connect 規範，所以「使用 Google 登入」背後走的就是 OIDC。至於 Kerberos、LDAP 這類較舊的機制，多半出現在公司內部網路，知道有這回事就夠了。
單一登入在使用者端與管理端的好處
單一登入的好處分成兩側，使用者要記的東西變少，管理者要處理的入口也變少。對十幾人的小團隊來說，感受最明顯的通常是離職那一刻，帳號能不能一次收乾淨。
要記的密碼變少，仿冒的登入頁也更好辨認
人記不住十幾組密碼，就會拿同一組走天下，或改用簡單好記的密碼，這就是密碼疲勞的來源。AWS 的說明指出，SSO 能減輕密碼疲勞，並鼓勵使用者建立強密碼，忘記密碼的情況也會減少。對管理者而言，Microsoft Learn 提到使用者保管的憑證變少、登入次數變少，送到服務台的密碼重設與帳號事務也跟著減少。
另一個常被漏講的好處，是入口集中。每個服務各有一個登入頁，就多一個可能被假冒的入口；改成固定從同一個入口登入，使用者比較容易察覺哪個頁面不對勁。這一點是依通則做的推論，並不是哪家廠商的結論，不過邏輯不難理解，天天走同一個入口，陌生的仿冒頁面就顯得突兀，使用者也比較不容易在假頁面輸入密碼。
開帳號與收回權限都只改身分提供者一處
管理端最實在的好處在這裡。新人到職，在身分提供者開一次帳號、指派工具就完成；人員離職或合作結束，一次停用，所有連動的工具同時失去入口。Microsoft Learn 的說明是，管理者從一個身分提供者控管存取，並套用一致的政策；Google Workspace 的說明也提到，搭配目錄同步之後，身分提供者那端新增或刪除的使用者，會自動在 Workspace 新增或刪除。
每個工具各自有一組帳號的時候，最容易漏掉的，是不常登入的那幾個，例如偶爾才用一次的素材平台，或某個專案結束後就沒人再開的協作工具，沒有人記得它們掛在誰的名下。「人走了帳號還在」的問題，SSO 提供的是結構性的解法，不必靠記憶逐一盤點。
不過要提醒，網域、主機、金流這類服務的帳號，往往不在單一登入的範圍內，通常得另外盤點、另外收回，不會因為公司接了 SSO 就一併處理掉。
登入紀錄集中在一處，事後追查更省力
登入全部經過同一個入口，登入紀錄也自然集中。出事時，管理者能回頭查「誰、何時、從哪裡登入了哪個工具」，用途包括追查異常登入，以及確認離職的人之後有沒有殘留使用。AWS 的說明也把促進使用者存取稽核列為好處之一。
這個好處主要對有團隊的公司有用。一個自由工作者，或兩三個人的小公司，登入紀錄本來就看得過來，多半用不到這一點，不必為了它特地導入。
SSO 把鑰匙集中，風險也跟著集中
把十扇門換成一把萬用鑰匙，方便是真的，但鑰匙一旦被複製，十扇門就同時失守。單一登入本身並非不安全，它的特性是把安全的賭注全壓在登入那一步。實際會遇到的風險有三種，其中一種還有真實發生過的事件，可以看出風險不只出在密碼。
一組帳號被盜，所有連動的服務一起失守
最直接的風險是帳密被盜。攻擊者一旦拿到你的 SSO 帳密，就能直接進入所有連動的服務，傷害範圍等於這個帳號連到的全部範圍；帳密常見的外洩來源是釣魚頁，或是在別處外洩、又被你重複使用的密碼。前面提過的個人場景同樣成立，同一個 Google 帳號登入了很多網站，這個 Google 帳號就是那把萬用鑰匙。
單一登入也不等同於 MFA。Microsoft Entra 驗證強度文件的對照表，把「聯合單因素」（Federated single-factor，也就是只靠 SSO 帳密登入）排除在 MFA 強度之外；要再搭配簡訊、語音、推播或 OATH 權杖（產生一次性驗證碼的硬體或 App）這類「擁有的東西」，或由身分提供者那一端本身完成多重要素驗證（Federated multifactor），才符合 MFA 強度。換句話說，只靠密碼的單一登入，仍然是單因素驗證，也就是只驗了一種東西，這也是 SSO 帳號比任何單一工具的帳號都更值得保護的原因。
工作階段憑證被竊，攻擊者不需要密碼
這是最少人聽過、卻最值得知道的一種。登入成功之後，瀏覽器或服務手上會握有一份「已登入」的憑證，也就是工作階段權杖。這份權杖一旦被偷，攻擊者不必知道密碼，一般來說也不會被 MFA 擋下，因為 MFA 驗證的是登入的那一刻，憑證簽發之後，用它存取服務通常不會再被要求重新驗證。Google 的 OIDC 文件提醒，ID 權杖是敏感資料，被攔截後可能遭濫用，必須妥善處理；OWASP 的 SAML 檢查表則建議 SAML 回應採用短效期，並優先設成只能使用一次（OneTimeUse），降低被偷後重複使用的風險。
Okta 2023 年公布的事故根因報告，是這類風險的真實案例。報告指出，2023 年 9 月 28 日至 10 月 17 日之間，攻擊者存取了 Okta 客服案件管理系統裡的檔案，其中有些是 HAR 檔（記錄瀏覽器連線過程的檔案），內含可用於工作階段劫持的工作階段權杖。共有 134 位客戶（不到 Okta 客戶總數的 1%）的檔案被存取，其中 5 位客戶的工作階段被實際劫持。Okta 的因應包括停用被入侵的服務帳號、撤銷 HAR 檔內嵌的工作階段權杖；事發當時的公告也建議，分享 HAR 檔之前，先清掉裡面所有的憑證與 cookie、工作階段權杖。報告也說明，攻擊者是透過一個服務帳號進入，該帳號的帳密存放在員工的個人 Google 帳號裡，最可能的外洩途徑，是那個個人帳號或個人裝置遭到入侵。
這個案例的重點，不在評論哪一家服務，而在「登入狀態」本身就是一份可以被偷走的憑證。放到日常工作上，做法很直接。把螢幕紀錄或瀏覽器紀錄交給任何第三方之前，不論是客服、外包還是合作夥伴，先清掉裡面的敏感內容；必要時事後登出再重新登入，縮短那份憑證可被使用的時間。
身分提供者停擺或設定出錯的連鎖影響
另外兩個風險比較少人事先想到。第一個是身分提供者本身出問題，例如服務當機、帳號被停用、忘了續約，所有只能走 SSO 的工具會一起進不去。這是從結構推得的結論，不是哪份報告的數字，但對小公司的意義很實在，就是要保留一組緊急備援的登入方式，例如少數管理者專用、離線保存的備援帳號，而且要確保有人知道它放在哪裡。
第二個是設定出錯。單一登入管的是全部工具，所以設錯的後果也比單一工具設錯來得大，權限給太廣，就可能讓不該進來的人進來。以 SAML 為例，OWASP 的檢查表列出了常見的實作要點，包括服務提供者要用本地可信的金鑰驗證簽章，要核對 Destination 與自己的 Assertion Consumer Service 網址完全一致、Audience 與自己的 EntityID 相符，避免斷言被拿到別的服務重複使用。這些是做整合的人要處理的事，知道有這回事，請人設定時就能多問一句。
守住 SSO 入口的 3 道防線
防護的重點有三個：用 MFA 守住登入那一關，降低帳號被盜的機會；人員異動時從一處收回權限，避免「人走了帳號還在」；再依角色配置權限、定期檢視登入紀錄，減少設定出錯的影響，也及早發現異常登入。
身分提供者那一關要開 MFA，並優先選抗釣魚的方式
既然賭注都壓在一個入口，這個入口就一定要加第二道驗證。第一層是有 MFA 比沒有好得多。Microsoft 研究團隊的 Meyer 等人在 2023 年，以 Microsoft Azure AD 的大規模資料評估，發現 MFA 讓帳號被入侵的風險整體降低 99.22%，在憑證已經洩漏的情況下，仍降低 98.56%。
第二層是不同的 MFA 方式，強度並不一樣。同一份研究也指出，專用的驗證器 App（例如 Microsoft Authenticator）表現優於簡訊，不過兩者都顯著優於沒有 MFA。簡訊與推播通知比較容易被釣魚，或被「推播轟炸」騙過，也就是攻擊者連續送出登入通知，等使用者不耐煩按下同意。美國網路安全暨基礎設施安全局（CISA）的〈Implementing Phishing-Resistant MFA〉說明文件，把抗釣魚 MFA 稱為 MFA 的黃金標準，它能抵擋釣魚，推播轟炸、SIM 卡調包這類攻擊也對它不管用；而目前廣泛可用的抗釣魚驗證只有 FIDO／WebAuthn（實體安全金鑰與通行金鑰背後的標準）。一時還無法導入抗釣魚 MFA 的中小企業，CISA 認為最好的選項是驗證器 App 產生的一次性驗證碼，或加上號碼比對（登入時要在手機上輸入畫面顯示的數字）的推播通知，號碼比對能擋下推播轟炸。
Microsoft 驗證強度文件裡，內建的「抗釣魚 MFA」強度只包含 Windows Hello for Business 或平台憑證、FIDO2 安全金鑰，以及多重要素的憑證式驗證，簡訊登入不在其中。對中小企業比較務實的做法，是至少使用驗證器 App，有條件的話，再把管理員帳號升級到安全金鑰或通行金鑰。
人員離職時停用帳號並撤銷工作階段
集中管理反過來成了收回權限的優勢。主要的動作是停用身分提供者那個帳號，所有走 SSO 的工具就同時失去入口。不過還有三件事要一併處理：
- 沒有接 SSO、只走帳密的工具，要另外收回。
- 已經登入中的工作階段與權杖，要一併撤銷，光改密碼不夠。
- 交接時，要確認這個人是不是某個工具的唯一管理員。
第二點在 Okta 的事故報告裡可以看得很清楚，他們的因應同時包含停用服務帳號與撤銷 HAR 檔內嵌的工作階段權杖，可見「停帳號」和「撤銷工作階段」是兩件事。第三點則是一個常見的盲點，某個工具只有這位離職者握有管理員權限，帳號一停用，反而沒人能處理那個工具的設定與帳單。
依角色配置工具權限並定期檢視登入紀錄
最小權限原則的白話版，是每個人只拿到工作需要的工具，不因為方便就全部開放。單一登入讓權限配置集中、容易管理，建議依角色（例如設計、行銷、財務）而不是依個人配置；但誰該有哪些權限，仍然要人來決定。敏感的工具，像金流、網域、主機，可以要求更強的驗證。Microsoft Entra 驗證強度文件就舉了這個做法，針對敏感資源，只允許抗釣魚的 MFA；非敏感資源，則允許較寬鬆的 MFA 組合。
另一件事是定期看登入紀錄，留意有沒有陌生地點、非工作時間的異常登入，並停用長期不用的帳號。這兩件事都不費力，卻能補上設定完成之後最容易被忽略的缺口。
中小企業與網站經營者導入 SSO 的實際考量
多數設計師與小公司沒有專職 IT，SSO 對他們不是越早導入越好，而是要看團隊規模、手上工具的方案門檻，以及有沒有現成的帳號系統可用，再決定要不要走這一步。
小團隊先做好帳號基本功，管理出錯時再導入單一登入
一個人或兩三人的團隊，工具不多、人員穩定，把每個帳號都開好 MFA、再配一套密碼管理員，往往比硬上單一登入實在。安全的起點不在 SSO，而在帳號的基本功，也就是強密碼、MFA，以及離職時的帳號盤點。
等到工具變多、有外包與離職交接、開始有人用不同帳號登入同一個工具，手動管理出錯的機率拉高，集中管理的價值才會浮現。這個判斷沒有固定的工具數量門檻，要看的是現在的管理方式，還撐不撐得住人員與工具的變動。
不少協作工具把 SAML 單一登入放在較高階方案
中小企業最容易踩到的現實是，工具支援 SSO，不代表你買的那個方案能用。「支援社群登入」與「支援公司自己的 SAML SSO」是兩件事，不少協作工具把後者放在較高階的方案，前者通常沒有這個限制。
以兩個知名工具為例。Notion 的官方說明目前寫的是，SAML SSO 只提供給 Business 方案或 Enterprise 方案的使用者；Slack 的官方說明則列出 Business+ 與 Enterprise 方案可用，另有已將 Salesforce 組織連到 Slack 時，Free 與 Pro 方案也能使用的例外。方案內容會調整，所以導入之前，先列出現在使用的工具，再逐一查官方說明的方案條件，比聽到「支援 SSO」就直接假設自己的方案有，來得穩當。
用現有的 Google Workspace 或 Microsoft 帳號系統當身分提供者
多數小公司其實已經有現成的身分提供者。公司信箱若用 Google Workspace 或 Microsoft 365，這組帳號系統本身就能當單一登入的來源，不必另外買一套專門的服務。Google Workspace 可以把工作工具加成 SAML 應用程式，讓員工用公司管理的 Google 帳號登入；Microsoft Entra ID 當身分提供者時，使用者用工作憑證登入一次，應用程式也不再各自管理帳密。
做法的思路是，管理者在後台設定哪些工具走這組帳號登入，以及用 SAML 還是 OIDC，這要看工具端與身分提供者兩邊共同支援哪一種。這是從現有的東西開始的路；專門的 SSO 與身分管理服務，是規模變大之後才需要考慮的下一步。
自家網站提供 Google、Apple 登入時要先想好的事
換成網站經營者的視角，要考慮的是自己的會員網站或電商，該不該加上「使用 Google 登入」、「使用 Apple 登入」。好處很明確，註冊門檻低，網站也不必自己保管會員密碼。決定之前，有三件事要先想好：
- 保留其他登入方式與會員信箱當備援，因為會員若只用社群帳號登入，那個帳號被停權或忘了怎麼登入時，他就進不來。
- 先向 Apple 登錄寄信的網域與信箱，因為 Apple 的「隱藏我的電子郵件」給的是轉寄信箱，依 Apple 白皮書，開發者要透過私密轉寄服務寄信，必須先登錄網域與信箱；會員若關閉轉寄，寄出的信件也會被退回。
- 在後端驗證 ID 權杖，並防範偽造請求，因為 Google 的文件說明，伺服器端流程要建立防偽造的 state 權杖並在回應時核對；ID 權杖若會在網站的不同元件之間傳遞，使用前一定要先驗證。
第三件事是做登入功能的人要處理的，不是設計師靠調整外觀就能解決的。經營者只要知道有這回事，在請人開發時能提出需求就夠了。
WordPress 的 SSO 通常要靠外掛接入
網站用 WordPress 的話，要讓後台或會員登入接上公司的帳號系統，通常得靠外掛處理，WordPress 外掛目錄裡可以搜尋到支援 SAML 或 OIDC 登入的外掛。外掛是否收費、支援哪些身分提供者，各家不同，選用之前要先讀外掛頁，確認它支援的協定，以及免費版的功能範圍。
如果網站只有一兩位管理者，把後台的登入保護做好，像是開啟 MFA、限制登入失敗的次數，通常比接上 SSO 更實際，也更快見效。
SSO 的價值，在於把登入集中到一個值得信任的入口；也因為集中，那個入口值得比任何單一工具更嚴格地保護。對多數設計師與小公司來說，比導入單一登入更值得先做的，是把手上每個帳號的 MFA 開起來，再把離職時要收回的帳號列成一張名單。等工具與人員多到手動管理開始出錯，再回頭評估 SSO，就比較清楚該從現有的公司帳號系統做起，還是需要專門的身分管理服務。