單一登入：SSO 與企業 WiFi 指南

您可能已經在處理這種情況了。員工登入 Microsoft 365，接著是訂位工具，然後是 HR，再到特定業務應用程式，最後是企業 WiFi，而且通常每一種都使用不同的方法。飯店集團在總部有一套系統，在飯店物業內又是另一套。醫院有臨床應用程式、共用工作站和分段的無線存取。零售營運商的員工則在門市、平板電腦、POS 和後台儀表板之間移動。

這種混合配置很快就會產生摩擦。使用者遺忘密碼、IT 團隊重設帳戶，而共享的 WiFi 認證在早就該被清除之後依然殘留。這導致的結果不僅僅是困擾， 更是降低了對於誰能從何種裝置存取何種內容以及存取多久的控制力。

這就是 單一登入（即 SSO）派上用場的地方。如果您正在搜尋 什麼是單一登入，簡單的回答很簡單：它讓使用者只需驗證一次，即可存取多個經核准的系統，而無需反覆輸入憑證。更有用的回答在於營運面。SSO 為 IT 提供了一個用於存取應用程式的身分識別層，而且在合適的設計中，它還可以支援人員和裝置加入安全網路的方式。

終結密碼混亂

大多數企業環境並非刻意變得混亂，而是隨著業務發展而逐漸演變成這樣。一個雲端應用程式變成了五個；一個辦公室變成了多個據點；一個原先供 IT 使用的無線網路，拆分成了給員工、訪客、承包商和裝置使用的不同 SSID。

這就是密碼漫延的開始。員工在開始實際工作之前，可能需要電子郵件、HR 系統、排班、檔案存取、內部儀表板和網路存取。IBM 將 SSO 描述為一種配置，使用者只需使用一組憑證登入一次，即可在同一工作階段中存取多個應用程式，這是透過服務提供者與身分識別提供者之間的信任關係來實現的。IBM 對於 單一登入 的概述，非常貼合英國組織在雲端導入和遠距工作加速時的需求。

密碼亂象對營運的影響

當每個應用程式都要求各自的登入資訊時，使用者就會開始走捷徑。他們會重複使用密碼、將密碼儲存在瀏覽器中，或者向同事詢問「員工 WiFi 密碼」，因為這比等待 IT 人員處理更快。

對於企業 IT 經理而言，控制權是首要考量。獨立的登入方式會創造出孤立的存取孤島，當人員調動職務、離職或跨多個據點工作時，這些孤島將更難以管理。

密碼混亂很少是單一的重大失敗。它通常是由數百個無人能持續管理的小型存取決策所累積而成的。

為什麼 SSO 能改變現狀

SSO 減少了使用者需要密碼管理的數量，這改善了登入體驗，並在與中央策略和 MFA 搭配使用時支援更強大的安全性。它也符合分散式組織的實際情況，在這些組織中，員工在電子郵件、人力資源、預約工具、POS、內部應用程式和現場服務中都需要單一登入。

同樣的邏輯現在也正在形塑網路存取。如果您已經開始針對應用程式採用身份導向的存取，那麼將免密碼 WiFi 視為相同設計方法的一部分，而不是當作獨立的問題來處理，是極具意義的。

理解核心 SSO 概念

SSO 將身分驗證從各個獨立的應用程式轉移出去，並將其置於單一受信任的身分系統中。使用者只需登入一次，驗證該身分，已連線的服務就會接受該結果，而不需要再次要求輸入密碼。

這聽起來很簡單，但其價值在於架構。您正在改變信任關係存在的位置。

每個 SSO 流程中的三個參與方

每個 SSO 設計都有三個參與者，且各自負責不同的工作：

• 使用者：想要存取應用程式、服務或網路資源。
• 身分識別提供者（IdP）：驗證身分並套用登入策略。英國組織中常見的範例包括 Microsoft Entra ID 和 Okta。
• 服務提供者（SP）：使用者嘗試連接的系統，例如 Salesforce、訂位平台、內部網路或其他業務系統。

常讓人感到困惑的一點是「信任」。應用程式本身並不需要收集和檢查密碼，而是依賴 IdP 來正確執行該項工作，然後接受其結果。

信任關係的真正含意

Auth0 以企業術語清楚解釋了 SSO：IdP 對使用者進行一次驗證，然後核發工作階段構件或權杖，供受信任的服務提供者驗證以便後續存取。在實際操作中，使用者會被重導向至 IdP，在該處進行驗證，然後返回各個應用程式，而無需重複提示輸入憑證。Auth0 關於 單一登入如何運作 的指南，在跨 SaaS 和內部系統使用 Entra ID 的英國環境中特別具有參考價值。

一個實用的理解方式如下：

1. 使用者開啟應用程式。
2. 應用程式檢查受信任的 IdP 是否已對該使用者進行身分驗證。
3. 如果不存在作用中的工作階段，使用者將登入 IdP。
4. IdP 確認身分並傳回應用程式可以驗證的證明。
5. 其他已連接的系統可以在工作階段期間接受該相同證明。

實用規則：SSO 並非將每個系統變成單一平台。它為多個系統提供了一個驗證身份的單一場所。

為什麼這在 Web 應用程式之外也很重要

這也是 SSO 不再僅僅是 SaaS 便利工具的地方。一旦身分集中化，同一個模型不僅能用於瀏覽器工作階段， 還能用於塑造您如何控制內部服務的存取，並在合適的設計中，控制使用者如何加入企業無線網路。

這對 IT 營運至關重要。財務應用程式、VPN 工作階段和員工 WiFi 連線可能是不同的服務，但它們都始於同一個問題：這個使用者是誰，是否應該允許其進入？當 Entra ID 或 Okta 一致地回答該問題時，跨應用程式和網路進入點的存取策略就會變得更容易管理。

對於仍在使用共用密碼執行員工 WiFi 的團隊來說，這是一個重大的轉變。您不再是使用每個人都知道的密碼來驗證裝置，而是根據受信任的身分識別來源來驗證個人或受管裝置。這為您提供了更嚴格的控制、更清晰的稽核追蹤，以及在角色變更或離職時更乾淨地移除存取權限的方式。

SSO 如何運作：核心協定

使用者體驗看起來很簡單。但在底層，SSO 仰賴標準協定，讓應用程式能夠信任在其他地方做出的身份驗證決策。

對於企業 IT 經理而言，實際的問題不僅僅是 "什麼是 SSO？" 而是 "一個系統如何在不要求使用者再次登入的情況下，接受來自另一個系統的證明？" 答案取決於在應用程式、身分識別提供者以及有時在裝置本身之間移動身分識別資料的一小部分協定。

這在瀏覽器登入之外也非常重要。當這些存取決策與 Microsoft Entra ID、Okta 或其他中央身分來源綁定時，用於開啟 SaaS 應用程式的同一個信任模型，也可以影響使用者連線到 VPN、有線網路和企業 WiFi 的方式。

通俗易懂的 SAML 介紹

SAML 2.0 在企業 SSO 中仍然很常見，特別是在已發展成熟的 SaaS 平台和特定業務系統中。

SAML 的工作原理是在應用程式和身分識別提供者之間傳遞受信任的身分宣告。使用者嘗試開啟應用程式。應用程式將他們重導向至 IdP。IdP 對使用者進行驗證並傳回數位簽章的判斷提示。應用程式檢查該簽章、接受身分宣告並建立工作階段。

這種流程適合瀏覽器承擔大部分工作，且應用程式預期進行正式、基於標準之交換的環境。

SAML 通常非常適合：

• 企業級 SaaS - 例如人資、財務或舊版商務應用程式
• 基於瀏覽器的工流程 - 使用者透過網頁工作階段存取系統
• 集中式原則執行 - 當 IT 團隊希望有一個統一的平台來管理驗證時

用通俗語言解釋 OAuth 與 OIDC

OAuth 2.0 最初是作為一種在不共用完整憑證的情況下授予資源有限存取權限的方法。就其本身而言，它與授權（Authorisation）有關。

OpenID Connect (即 OIDC) 在 OAuth 2.0 之上增加了身分識別。這為現代應用程式提供了一種標準方式來確認使用者是誰，同時仍然使用基於權杖的存取模式。如果 SAML 通常適用於較舊的、以瀏覽器為中心的 SaaS，那麼 OIDC 通常適用於較新的 Web 應用程式、行動應用程式和 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 的斷言 (Assertions)	基於權杖 (Token) 的流程
典型流程	重導向至 IdP，進行驗證，返回已簽署的斷言	重導向或權杖流程，然後應用程式使用權杖進行身分識別和存取
最佳契合	傳統企業 SSO 整合	較新的雲端原生和以應用程式為中心的架構

IT 經理關心的重點

協定名稱不如設計選擇重要。您需要對以下四個營運問題有明確的答案：

• 哪些應用程式支援 SAML 或 OIDC
• 哪一個 IdP 將作為您的中央控制平面
• 如何執行工作階段逾時、MFA 和條件式存取
• 網路存取（包括員工 WiFi）是否也應該針對該相同的來源驗證身分

最後一點正是 SSO 對基礎架構團隊特別有用的地方。如果您的無線平台可以使用與您的 SaaS 資產相同的身分識別層，則從登入頁面到網路邊緣，存取策略會變得更加一致。這也是許多正在評估 單一登入在存取控制與營運方面的好處 的團隊，不僅看 Web 應用程式登入，也開始尋找以身分識別為後盾的 WiFi 驗證之原因之一。

評估效益與安全折衷

SSO 通常被當作一種方便使用者的功能來銷售。這低估了它的價值。如果做得好，它是一種存取控制模型，可以同時改善使用者體驗並加強營運安全。

Okta 指出，SSO 的技術優勢不僅僅是便利。它減少了密碼蔓延和重複登入事件，進而降低了技術支援中心的負載與使用者摩擦。Okta 針對 單一登入安全性 的概述中，也強調了一個架構師非常關心的重點：如果 IdP 工作階段失效，已連接的應用程式可以在下一次權杖檢查時拒絕存取。

業務價值的體現之處

第一個好處是更簡單的存取。使用者只需登入一次，就能更快開始工作，不再將身份驗證視為日常障礙。

第二個好處是更強的中央控制。IT 人員可以從單一身份層級套用 MFA、條件式存取、工作階段原則和撤銷權限，而不必在每個應用程式中逐一調整設定。

第三個好處是更乾淨的新進、異動、離職處理。當身分集中管理時，入職和離職流程會變得更加一致。這也是探索 single sign-on benefits 的團隊經常將 SSO 專案與更廣泛的身分治理解決方案連結起來的原因之一。

您應該認真對待的權衡取捨

這確實存在「掌握關鍵鑰匙」的疑慮。如果攻擊者破解了使用者的主要登入帳戶，受害範圍可能會更大，因為一個帳戶就可能提供多個系統的存取權限。

此外也存在韌性風險。如果身分識別提供者（IdP）無法使用，對已連線服務的存取可能會中斷。而且整合並不總是那麼順暢。較舊的應用程式、小眾系統和本機網路服務並不總是能完美契合現代的 SSO 模型。

正確的問題不在於 SSO 是否需要權衡折衷，而是在於您寧願集中管理這些折衷，還是要繼續管理數十個分散的系統。

常見的緩解措施

使用分層方法：

• 對 IdP 進行重度保護：使用 MFA、條件式存取、裝置信任和強大的管理員控制。
• 規劃彈性：使 IdP 的問題不會導致整個組織陷入停擺。
• 分階段推出：從高價值應用程式和明確的使用者群組開始。
• 定期審查存取權限：使過期的權利在不再需要之後不會保留太久。

不夠完善的 SSO 部署可能會使問題集中化。而強大的部署則能實現集中化控制。

超越網頁應用程式的 SSO：網路與 WiFi 存取

大多數文章只討論到 SaaS。這雖然有用，但並不完整。在真實環境中，員工不僅需要存取應用程式。當他們到達現場、連接受管理的筆記型電腦、在分店打開平板電腦或在不同據點之間漫遊時，他們都需要安全的網路存取。

這就是 SSO 討論變得更有趣的地方。處理 Microsoft 365、人事系統或內部儀表板存取的同一個身份識別提供者，也可以成為無線驗證原則的單一信任源。

Optimal IdM 在其探討 單一登入採用率 的文章中指出，52% 的北美 IT 專業人員使用 SSO 進行身分識別管理。對於擁有多個場地或物業的英國組織來說，這種成熟度至關重要，因為員工通常需要安全地存取共用系統，而無需重複登入。

應用程式 SSO 與網路身份相關，但並不完全相同

讀者常感到困惑的一個點在於，應用程式的 SSO 與基於身份的網路存取雖然是相關的概念，但兩者並非相同的機制。

應用程式 SSO 通常是指使用者向 IdP 驗證一次，並取得已連接應用程式所接受的權杖或工作階段。網路存取通常使用不同的控制措施，例如裝置憑證、無線驗證方法、目錄支援的原則，以及安全狀態或信任檢查。

連結它們的是身分來源。如果 Microsoft 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 與訪客或裝置存取之間的區別日益明顯，並在其關於 單一登入運作原理 的說明中提出了一個對買家非常有用的問題：什麼時候 SSO 是錯誤的工具？什麼時候應該將識別應用於網路存取而非應用程式登入？

這在 WiFi 設計中至關重要。員工通常應該使用與身分連結、由原則驅動的存取。訪客通常需要更輕量、更簡單且獨立的存取方式。試圖將所有存取問題強加於員工 SSO，會在不需要的地方製造摩擦。

如果您正在評估將 SSO 作為更廣泛存取策略的一部分，請在同一個討論中納入應用程式、員工 WiFi、訪客入網、共享裝置以及撤銷工作流程。這通常是營運效益提升最顯著的地方。

---

如果您正在重新思考應用程式、員工 WiFi、訪客引導或多租戶網路的存取方式，Purple 值得一試。它提供識別導向的網路，可與 Entra ID、Okta 和 Google Workspace 等平台協同工作，幫助團隊以針對員工、訪客和住戶的受控存取，取代共用密碼和繁瑣的 Captive Portal。