您可能已經在處理這種情況。員工登入 Microsoft 365，接著是預約工具、人事系統、業務應用程式，然後是企業 WiFi，而且通常每一種系統的登入方式都不同。飯店集團在總部有一套系統，在飯店現場又是另一套。醫院有臨床應用程式、共享工作站和細分的無線存取。零售業者則有員工在不同門市、平板電腦、POS 和後台儀表板之間移動。
這種混合情況很快就會產生摩擦。使用者忘記密碼，IT 團隊重設帳戶，而共用的 WiFi 憑證在應該被刪除後仍長期留存。結果不僅僅是令人煩惱，這還意味著對於誰能從哪種裝置存取什麼內容、以及存取多久的控制力變得更弱。
這就是 single sign-on（單一登入，或稱 SSO）發揮作用的地方。如果您正在搜尋 what is single sign on，簡短的答案很簡單：它讓使用者只需驗證一次，即可存取多個核准的系統，而無需一次又一次地輸入憑證。更有用的答案則是營運層面的。SSO 為 IT 提供了一個用於存取應用程式的單一身分識別層，而且在合適的設計中，它還能支援人員和裝置如何加入安全網路。
結束密碼混亂
大多數企業環境並非刻意變得混亂，而是隨著發展而演變成的。一個雲端應用程式變成了五個。一個辦公室變成了多個據點。一個供 IT 使用的無線網路變成了供員工、訪客、承包商和裝置使用的獨立 SSID。
這就是密碼蔓延的起因。一名員工可能需要電子郵件、人事、排班、檔案存取、內部儀表板和網路存取，然後才能開始進行任何實際工作。IBM 將 SSO 描述為一種配置，使用者只需使用一組憑證登入一次，即可在同一工作階段中存取多個應用程式，這是透過服務提供者與身分識別提供者之間的信任關係來實現的。IBM 對於 single sign-on 的概述，非常貼合英國組織在雲端採用和遠端工作加速時的需求。
密碼蔓延對營運的影響
當每個應用程式都要求獨立登入時，使用者就會開始走捷徑。他們會重複使用密碼、將密碼儲存在瀏覽器中，或者向同事詢問「員工 WiFi 密碼」，因為這比等待 IT 處理更快。
對於企業 IT 經理來說，控制權是首要考量。獨立的登入會創造出獨立的存取孤島，而當人員調整職責、離職或跨多個地點工作時，這些孤島就會變得更難以管理。
密碼混亂很少是一次性的大型失敗，它通常是由數百個沒人能持續管理的小型存取決策所累積而成的。
為什麼 SSO 能改變局面
SSO 減少了使用者需要管理的密碼數量，進而改善登入體驗，並在與集中原則和 MFA 搭配使用時支援更強大的安全性。這也符合分散式組織的實際需求，其員工需要在電子郵件、HR、預約工具、POS、內部應用程式和現場服務之間使用單一登入。
同樣的邏輯現在正在形塑網路存取。如果您已經開始為應用程式轉向以身分為導向的存取，那麼將 passwordless WiFi 視為相同設計方法的一部分，而不是作為一個單獨的問題來處理，是很有道理的。
瞭解 SSO 的核心概念
SSO 將驗證從各個獨立的應用程式中移開，並將其置於單一受信任的身分識別系統中。使用者只需登入一次，該身分即被驗證，且連線的服務會接受該結果，而不會要求輸入另一個密碼。
這聽起來很簡單，但其價值在於架構。您正在改變信任存在的地方。
每個 SSO 流程中的三個參與者
每個 SSO 設計都有三個參與者，每個參與者都有不同的工作：
- 使用者：想要存取應用程式、服務或網路資源。
- 身分識別提供者或 IdP：驗證身分並套用登入原則。英國組織中常見的範例包括 Microsoft Entra ID 和 Okta。
- 服務提供者或 SP：使用者嘗試存取的系統，例如 Salesforce、預約平台、內部網路或其他業務系統。
經常引起混淆的一點是信任。應用程式本身不需要收集和檢查密碼。它依賴 IdP 正確執行該工作，然後接受其結果。
信任關係的真實含意
Auth0 以企業術語清楚解釋了 SSO：IdP 對使用者進行一次驗證，然後發行工作階段成品或權杖，受信任的服務提供者會驗證該權杖以供稍後存取。在實務上，使用者會被重導向至 IdP 並在那裡進行驗證，然後返回各個應用程式，而不需要重複輸入認證提示。Auth0 的 單一登入運作方式 指南對於在 SaaS 和內部系統中使用 Entra ID 的英國環境特別具有參考價值。
更實用的理解方式如下：
- 使用者開啟應用程式。
- 應用程式檢查受信任的 IdP 是否已驗證該使用者。
- 如果不存在有效的工作階段，使用者將透過 IdP 登入。
- IdP 確認身分並傳回應用程式可以驗證的證明。
- 其他連接的系統可以在該工作階段期間接受相同的證明。
實用規則：SSO 並非將所有系統轉變為單一平台。它是為多個系統提供一個驗證身分的單一場所。
為什麼這在 Web 應用程式之外也很重要
這也是 SSO 不僅僅是 SaaS 便利之處。一旦身分集中化，同一個模型就可以用於瀏覽器工作階段以外的更多用途。它還可以決定您如何控制對內部服務的存取，並在合適的設計中，決定使用者如何加入企業無線網路。
這對 IT 營運至關重要。財務應用程式、VPN 工作階段和員工 WiFi 連線可能是不同的服務，但它們都始於同一個問題：這位使用者是誰，是否應該允許他們進入？當 Entra ID 或 Okta 一致地回答該問題時，跨應用程式和網路進入點的存取策略就會變得更容易管理。
對於仍在使用共享密碼執行員工 WiFi 的團隊來說，這是一個重大的轉變。您不再是使用每個人都知道的密碼來驗證裝置，而是根據信任的身分來源來驗證個人或受管裝置。這為您提供了更嚴格的控制、更清晰的稽核軌跡，以及在角色變更或雇用結束時移除存取權限的更乾淨方式。
SSO 的工作原理 - 核心協定
使用者體驗看起來很簡單。在底層，SSO 依賴標準協定，讓應用程式能夠信任在其他地方做出的身分決定。
對於企業 IT 經理來說，實際的問題不僅僅是 "什麼是 SSO？" 而是 "一個系統如何接受來自另一個系統的證明，而不需要要求使用者再次登入？" 答案取決於一小組協定，這些協定在應用程式、身分識別提供者以及有時在裝置本身之間行動身分資料。
這在瀏覽器登入之外也至關重要。當這些存取決策與 Entra ID、Okta 或其他中央身分來源綁定時，用於開啟 SaaS 應用程式的相同信任模型也可以影響使用者連線到 VPN、有線網路和企業 WiFi 的方式。
通俗易懂的 SAML
SAML 2.0 在企業 SSO 中仍然很常見，特別是在成熟的 SaaS 平台和特定業務系統中。
SAML 的工作原理是在應用程式和身分識別提供者之間傳遞受信任的身分宣告。使用者嘗試開啟應用程式。應用程式將他們重導向到 IdP。IdP 驗證使用者身分並傳回數位簽章的判斷式。應用程式檢查該簽章，接受身分宣告，並建立工作階段。
該流程適合瀏覽器執行大部分工作且應用程式預期進行正式、基於標準的交換的環境。
SAML 通常非常適合：
- 企業級 SaaS，如人力資源、財務或傳統商務應用程式
- 基於瀏覽器的工流程，使用者透過網頁工作階段存取系統
- 集中式策略執行，當 IT 部門希望在一個地方治理驗證時
通俗易懂的 OAuth 與 OIDC 介紹
OAuth 2.0 最初是作為一種在不分享完整認證資料的情況下，授予資源有限存取權限的方法。其本身主要關乎授權。
OpenID Connect（簡稱 OIDC） 在 OAuth 2.0 之上加入了身分識別。這為現代應用程式提供了一種標準方式來確認使用者身分，同時仍使用基於權杖的存取模式。如果說 SAML 通常適用於較舊的以瀏覽器為中心的 SaaS，那麼 OIDC 通常更適用於較新的網頁應用程式、行動應用程式和 API 驅動的服務。
在實務上，對於現代開發團隊而言，OIDC 通常感覺更輕量，因為權杖在前端應用程式、後端服務和行動用戶端之間的運作非常順暢。對 IT 部門來說，這意味著當應用程式不是傳統的瀏覽器工作階段時，可以減少棘手的因應措施。
OIDC 通常適用於：
- 現代雲端應用程式
- 行動與單頁應用程式
- API 密集型環境（權杖已是設計的一部分）
關於 Kerberos 的簡短說明
在 SSO 的討論中，您可能還會聽到 Kerberos。Kerberos 與傳統的 Active Directory 環境和內部部署 Windows 驗證密切相關。它在內部企業資產中仍然具有重要意義，特別是在加入網域的裝置和傳統應用程式仍然很常見的地方。
話雖如此，許多目前的 SSO 專案都專注於跨雲端和混合服務的同盟身分識別。在這些情況下，SAML 和 OIDC 通常會受到更多關注，因為它們能更自然地連接到 SaaS 平台和外部可存取的服務。
SAML 與 OIDC 一覽
| 功能 | SAML 2.0 | OAuth 2.0 / OIDC |
|---|---|---|
| 主要角色 | 企業網頁應用程式的驗證 | 透過 OIDC 加入身分識別的授權 |
| 常見使用場景 | 已建立的 SaaS 和基於瀏覽器的企業應用程式 | 現代網頁應用程式、行動應用程式、API |
| 格式 | 基於 XML 的判斷式 | 基於權杖的流程 |
| 典型流程 | 重新導向至 IdP、驗證、傳回已簽署的判斷式 | 重新導向或權杖流程，然後應用程式使用權杖進行身分識別和存取 |
| 最佳契合 | 傳統企業 SSO 整合 | 較新的雲端原生和以應用程式為中心的架構 |
對 IT 經理而言最重要的是什麼
協定名稱的重要性次於設計選擇。您需要對以下四個維運問題有明確的答案：
- 哪些應用程式支援 SAML 或 OIDC
- 哪個 IdP 將作為您的中央控制平面
- 將如何強制執行工作階段逾時、MFA 和條件式存取
- 網路存取（包括員工 WiFi）是否也應對照該相同來源驗證身分
最後一點正是單一登入對基礎架構團隊特別有用的地方。如果您的無線平台可以使用與 SaaS 資產相同的身分層，那麼從登入頁面到網路邊緣的存取原則都會變得更加一致。這就是許多在評估 單一登入對存取控制和維運的好處 的團隊，也開始關注以身分識別為基礎的 WiFi 驗證，而不僅僅是 Web 應用程式登入的原因之一。
衡量好處與安全折衷
SSO 通常被宣傳為一種方便使用者的功能。這低估了它的價值。如果做得好，它是一種存取控制模型，可以同時改善使用者體驗並加強維運安全性。
Okta 指出，SSO 的技術優勢不僅僅是便利性。它減少了密碼蔓延和重複登入事件，這些事件會增加技術支援團隊的負擔和使用者阻力。Okta 對 單一登入安全 的概述也強調了架構師關心的一點：如果 IdP 工作階段失效，連接的應用程式可以在下一次權杖檢查時拒絕存取。
業務價值的體現之處
第一個好處是更簡單的存取。使用者只需登入一次，就能更快開始工作，不再將身分驗證視為日常障礙。
第二個是更強大的中央控制。IT 可以從單一身分層套用 MFA、條件式存取、工作階段原則和撤銷，而無需在每個應用程式中逐一調整設定。
第三個好處是更乾淨的員工入職、異動、離職處理。當身分集中管理時，入職和離職作業會變得更加一致。這就是探索 單一登入好處 的團隊，通常會將 SSO 專案與更廣泛的身分治理工作相結合的原因之一。
您應該認真對待的折衷方案
確實存在「王國鑰匙」的擔憂。如果攻擊者破解了使用者的主要登入，其受害範圍可能會更大，因為一個帳戶可能就能存取許多系統。
這還伴隨著復原韌性風險。如果 IdP 無法使用，對已連接服務的存取可能會中斷。此外，整合並不總是那麼完美。舊版應用程式、小眾系統和本機網路服務並不總是能完美融入現代 SSO 模式。
正確的問題不在於 SSO 是否有權衡，而在於您更願意集中管理這些權衡，還是繼續管理幾十個中斷連接的權衡。
常見的緩解措施
使用分層方法：
- 透過 MFA、條件式存取、裝置信任和強大的管理員控制嚴密保護 IdP。
- 規劃復原韌性，使 IdP 問題不會導致整個組織陷入停頓。
- 從高價值應用程式和明確的使用者群組開始，分階段推出。
- 定期審查存取權限，使過期的權限在不再需要後不會保留太久。
不完善的 SSO 部署可能會使問題集中化。而強大的部署則能使控制集中化。
超越 Web 應用程式的 SSO - 網路與 WiFi 存取
大多數文章都只停留在 SaaS。這雖然有用，但並不完整。在實際環境中，員工不僅需要應用程式存取權限。當他們抵達現場、連接受管筆記型電腦、在分部打開平板電腦或在不同場所之間漫遊時，他們都需要安全的網路存取。
這正是 SSO 討論變得更有趣的地方。處理 Microsoft 365、人事系統或內部儀表板存取權限的同一個身分識別提供者，也可以成為無線驗證原則的單一信任來源。
Optimal IdM 報告指出，在關於 single sign-on adoption 的討論中，北美有 52% 的 IT 專業人員使用 SSO 進行身分識別管理。對於擁有多個場地或物業的英國組織而言，這種成熟度至關重要，因為員工通常需要安全存取共享系統，而無需重複登入。
應用程式 SSO 與網路身分識別相關，但並不相同
讀者常感到困惑的一點是，應用程式的 SSO 與基於身分識別的網路存取是相關的概念，但它們並非相同的機制。
應用程式 SSO 通常意味著使用者只需向 IdP 驗證一次，即可獲得已連接應用程式所接受的權杖或工作階段。網路存取則通常使用不同的控制措施，例如裝置憑證、無線驗證方法、目錄型原則以及狀態或信任檢查。
其核心關聯在於身分驗證來源。如果 Entra ID 或 Okta 已經知道使用者是誰、屬於哪個群組，以及其裝置是否受管理，您就可以利用該身分識別內容來決定他們是否能加入員工網路。
這在企業 WiFi 上呈現的樣貌
在成熟的設計中，員工完全不需要輸入共享的 WiFi 密碼。其組織管理的裝置已註冊、受信任，並與其身分建立關聯。當他們進入大樓時，裝置會使用憑證型或同等企業級驗證方式，自動連線到相應的安全 SSID。
這在維運上帶來了巨大的改變：
- 共享密碼消失了，因此單一認證憑證外洩不會影響整個員工網路。
- 存取變得具備角色感知，因為原則可以遵循身分群組。
- 撤銷變得更快，因為當目錄存取權變更時，網路存取權也會隨之變更。
- 漫遊變得更容易，特別是對於使用者期望在任何地方都能獲得相同體驗的多據點園區。
為什麼這在旅宿業、零售業和醫療保健業至關重要
這些行業充滿了邊緣案例。您有排班人員、共享裝置、派遣員工、漫遊團隊，以及對企業、半企業和訪客存取需求的持續混合。
飯店集團可能希望使用單一員工身分來管理跨物業的 PMS 存取、後勤應用程式和安全內部 WiFi。零售連鎖店可能希望受管理的掌上型裝置自動連線到門市 WiFi，同時保持訪客流量隔離。醫療保健提供者可能希望在臨床使用者、訪客和連線裝置之間進行更強的隔離。
這也是 網路存取控制解決方案 進入討論的地方。它們有助於將身分原則從應用程式層擴展到網路層。
Purple 的定位
一個實用的選擇是 Purple，它支援針對員工和多租戶環境的基於身分的網路，包括與 Entra ID、Google Workspace 和 Okta 的整合，可在不依賴共享密碼的情況下進行安全存取。當您希望應用程式身分和網路身分在同一個單一真實來源下運作時，這種方法非常有用。
SSO 在您產業中的實際應用案例
看清 SSO 價值的最簡單方法是看日常工作，而不是架構圖。
旅宿業
飯店營運經理在一個物業開始一天的工作，並在另一個物業結束。他們需要在這兩個位置存取排班系統、物業管理系統、共享文件和內部 WiFi。
使用 SSO，該身分會隨身同行。他們只需登入一次，經核准的系統就會辨識該工作階段。如果組織也將網路存取權與相同的身分來源連結，其託管裝置就會直接加入員工 WiFi，而不需要有人將最新的密碼傳簡訊給值班經理。
零售業
區域經理拿著平板電腦走進店內。他們需要立即使用銷售儀表板、庫存工具和內部溝通應用程式。
在零散的設定中，每次停頓都可能意味著另一個登入提示、另一個過期的密碼，或是另一通打給客服的電話。在以身分為導向的模型中，平板電腦能乾淨俐落地進行驗證，存取權限反映了使用者的角色，且店面員工不需要分享本地憑證即可完成工作。
優秀的 SSO 絕非讓存取變得隱形。它讓合法的存取變得可以預測。
醫療保健業
臨床醫生開始輪班，需要快速且受控地存取核心系統。在一天之中，他們可能會在工作站、共享裝置和受限的網路區段之間移動。
在此，SSO 有助於減少對核准應用程式的重複登入，而基於身分的網路控制則有助於確保正確的使用者和裝置連線到正確的無線環境。這種區隔非常重要。臨床存取、訪客存取和裝置存取不應該都以相同的方式進行管理。
多租戶物業與園區
在學生宿舍、商業中心和混合用途物業中，員工和住戶通常共存於相同的實體基礎設施上，但絕不應該共享相同的存取模型。
員工可能需要建築系統、支援工具和內部管理應用程式。住戶或租戶需要可靠的連線，但不需要存取營運平台。在這種情況下，身分設計最為重要。SSO 可以支援員工存取，而獨立的網路身分原則則能保持租戶和訪客流量的隔離。
SSO 導入與最佳實踐
成功的 SSO 專案始於一個決定：選擇將作為您控制平面的身分識別提供者。對許多組織而言，這會是 Microsoft Entra ID 或 Okta，因為這些平台已經與使用者生命週期、MFA 和裝置原則緊密結合。
部署應分階段進行。從最重要的應用程式和最有可能受益的使用者群組開始。在擴大範圍之前，先清理重複的帳戶、正確定義角色群組，並測試工作階段行為。
最重要的控制措施
以下幾項實踐決定了這是一個僅供展示的精美範例，還是耐久的部署：
- 在主要登入點要求 MFA。 如果一次登入可以提供多個資源的存取權，則該登入需要更強大的保護。
- 围绕立即撤銷建置離職流程。 唯有在帳戶變更快速生效的情況下，集中式身分才有用處。
- 按角色審查存取權限。如果沒有人檢查誰仍擁有存取權限，SSO 可能會讓人更容易忽略過度授權的問題。
- 規劃 IdP 中斷預案。了解身分驗證服務無法使用時會發生什麼情況，以及哪些系統需要備用處理機制。
了解何時 SSO 不是合適的工具
這一點在許多通俗的說明中常被忽略。OneLogin 指出，在實際部署中，員工 SSO 與訪客或裝置存取之間的區別越來越明顯，並在其關於 how single sign-on works 的說明中提出了一個對買家很有用的問題：何時 SSO 是錯誤的工具，何時應該將身分驗證應用於網路存取，而不是應用程式登入？
這在 WiFi 設計中非常重要。員工通常應該使用與身分連結、由原則驅動的存取方式。訪客通常需要更輕量、更簡單且獨立的存取方式。試圖將每個存取問題都強行通過員工 SSO 來解決，會在不需要的地方製造阻礙。
如果您正在將 SSO 作為更廣泛存取策略的一部分進行審查，請在同一次討論中納入應用程式、員工 WiFi、訪客引導、共享裝置和撤銷工作流程。這通常是能獲得最大營運效益的地方。
如果您正在重新思考應用程式、員工 WiFi、訪客引導或多租戶網路的存取方式， Purple 值得您參考。它提供基於身分的網路服務，可與 Entra ID、Okta 和 Google Workspace 等平台搭配使用，協助團隊以針對員工、訪客和居民的受控存取，取代共享密碼和繁瑣的 Captive Portal 。
