使用者討厭密碼。他們忘記密碼、重複使用密碼、把密碼寫在便條紙上，並在被迫建立新密碼時抱怨。組織也討厭密碼——它們產生服務台工單、造成安全漏洞、讓使用者感到沮喪。單點登入（SSO）作為解決方案應運而生：一次身份驗證，存取所有系統。
這個承諾聽起來很簡單，但現實卻很複雜。幾十年來，出現了多種 SSO 技術，每種都在不同的場景中解決不同的問題。Windows 整合身份驗證（WIA）在企業網路內工作。Kerberos 為分散式系統提供安全身份驗證。SPNEGO 連接了 Windows 和 Web 應用程式。SAML 實現了企業聯合。OAuth 革新了 API 授權。OpenID Connect（OIDC）最終統一了現代應用程式的身份驗證和授權。
本文追溯 SSO 從 1980 年代網路身份驗證到當今雲原生協定的演進。理解這段歷史揭示了為什麼我們有這麼多 SSO 標準、何時使用每一種，以及如何避免危及安全的常見身份驗證錯誤。
SSO 演進時間線
密碼問題
在研究 SSO 解決方案之前，理解它們要解決的問題至關重要。密碼在每個系統中都會產生摩擦和風險。
密碼為何失敗
密碼最初似乎是個好主意：
🚫 密碼問題
使用者負擔
- 記住數十個密碼
- 不同的複雜度要求
- 頻繁的過期政策
- 密碼重設摩擦
安全風險
- 跨系統重複使用密碼
- 為便於記憶使用弱密碼
- 釣魚攻擊竊取憑證
- 憑證填充攻擊
營運成本
- 服務台密碼重設工單
- 帳戶鎖定問題
- 配置複雜性
- 稽核追蹤缺口
典型的企業員工需要管理電子郵件、檔案共享、資料庫、Web 應用程式、VPN 和無數 SaaS 工具的密碼。每個系統都有不同的要求——最小長度、特殊字元、過期期限。使用者的反應是可預測的：他們重複使用密碼、寫下密碼，或使用簡單的模式，如「Password1」、「Password2」、「Password3」。
SSO 願景
單點登入解決了這些問題：
✅ SSO 優勢
使用者體驗
- 每個工作階段只需驗證一次
- 存取所有授權系統
- 減少密碼疲勞
- 更快的應用程式存取
安全改進
- 集中式身份驗證
- 更強的身份驗證方法
- 一致的安全政策
- 更好的稽核追蹤
營運效率
- 更少的服務台工單
- 簡化配置
- 集中式存取控制
- 減少管理開銷
這個願景很有吸引力：使用者早上驗證一次，然後無縫存取電子郵件、檔案共享、資料庫和 Web 應用程式，無需額外登入。安全性得到改善，因為身份驗證在一個地方進行，具有強大的控制。營運簡化，因為存取管理集中化。
早期 SSO：Kerberos 和 Windows
第一批實用的 SSO 實作出現在 1980 年代和 1990 年代，專為企業網路設計。
Kerberos：網路身份驗證協定
Kerberos 由 MIT 在 1980 年代開發，為分散式系統提供安全身份驗證：
🎫 Kerberos 基礎
核心概念
- 基於票據的身份驗證
- 可信第三方（KDC）
- 不透過網路傳送密碼
- 相互身份驗證
運作原理
- 使用者向 KDC 進行身份驗證
- KDC 頒發票據授予票據（TGT）
- 使用者使用 TGT 請求服務票據
- 使用者向應用程式出示服務票據
- 應用程式透過 KDC 驗證票據
Kerberos 解決了一個關鍵問題：如何在不傳送密碼的情況下跨網路驗證使用者身份。該協定使用對稱金鑰加密和可信的金鑰分發中心（KDC）。「Kerberos」這個名字來自希臘神話——守衛冥界的三頭犬，代表客戶端、伺服器和 KDC，它們共同保護身份驗證的安全。
2. 獲取 TGT| KDC Client <-->|請求服務票據| KDC Client -->|出示票據| Service1 Client -->|出示票據| Service2 Service1 -.->|驗證| KDC Service2 -.->|驗證| KDC style KDC fill:#f96,stroke:#333,stroke-width:3px style Client fill:#9cf,stroke:#333,stroke-width:2px
📖 深入了解：Kerberos
有關 Kerberos 架構、身份驗證流程、票據結構、安全考量和實作指南的詳細內容，請參閱理解 Kerberos：網路身份驗證詳解。
Windows 整合身份驗證
Microsoft 基於 Kerberos 建構了 Windows 網域身份驗證：
🪟 Windows 身份驗證演進
NTLM（NT LAN Manager）
- 挑戰-回應協定
- 無可信第三方
- 易受中繼攻擊
- 舊版協定，仍受支援
Active Directory 中的 Kerberos
- 自 Windows 2000 起預設使用
- Active Directory 作為 KDC
- 無縫桌面 SSO
- 適用於 Windows 應用程式
Windows 整合身份驗證（WIA）在企業網路內提供透明的 SSO。當你使用網域憑證登入 Windows 工作站時，你使用 Kerberos 向 Active Directory 進行身份驗證。你的工作站快取票據。當你存取檔案共享、內網網站或其他 Windows 整合應用程式時，你的工作站會自動出示相應的票據。你永遠不會看到另一個登入提示——它就是這樣運作的。
這種無縫體驗為 SSO 設定了使用者期望。員工想知道為什麼他們的桌面應用程式無需額外身份驗證就能運作，而 Web 應用程式卻需要單獨登入。
SPNEGO：連接 Windows 和 Web
SPNEGO（簡單和受保護的 GSSAPI 協商機制）將 Windows 身份驗證擴展到 Web 瀏覽器：
🌐 SPNEGO 用於 Web SSO
目的
- 將 Kerberos 擴展到 HTTP
- 瀏覽器協商身份驗證
- 對使用者透明
- 內網 SSO
運作原理
- 瀏覽器請求受保護的資源
- 伺服器回應 WWW-Authenticate: Negotiate
- 瀏覽器請求 Kerberos 票據
- 瀏覽器在 Authorization 標頭中傳送票據
- 伺服器驗證票據並授予存取權限
要求
- 加入網域的工作站
- 啟用 Kerberos 的瀏覽器
- 受信任區域中的伺服器
- 正確的 DNS/SPN 設定
SPNEGO 使內網 Web 應用程式能夠使用 Windows 身份驗證。員工存取公司入口網站時不會看到登入頁面——瀏覽器使用他們的 Windows 憑證自動進行身份驗證。這在企業網路內運作良好，但在網路外失敗。遠端員工、行動裝置和外部合作夥伴無法使用 Windows 身份驗證，這造成了後續協定將填補的空白。
企業聯合：SAML
隨著組織採用 Web 應用程式和雲端服務，他們需要超越企業網路的 SSO。SAML 成為企業聯合標準。
SAML 概覽
安全性判斷提示標記語言（SAML）實現跨組織邊界的 SSO：
🔐 SAML 核心概念
實體
- 身分提供者（IdP）：驗證使用者身分
- 服務提供者（SP）：提供應用程式
- 使用者：存取應用程式
關鍵特性
- 數位簽章的 XML 判斷提示
- 基於瀏覽器的重新導向流程
- 跨組織邊界運作
- 成熟的企業標準
SAML 將身份驗證與應用程式存取分離。身分提供者（IdP）處理身份驗證——驗證你是誰。服務提供者（SP）信任 IdP 關於你身分的判斷提示。當你存取啟用 SAML 的應用程式時，它會將你重新導向到組織的 IdP。你在 IdP 進行一次身份驗證，IdP 會頒發 SAML 判斷提示——一個數位簽章的 XML 文件，說明你是誰以及你擁有哪些屬性。
ADFS/Okta] SP1[服務提供者 A] SP2[服務提供者 B] User -->|存取| Browser Browser <-->|1. 重新導向到 IdP
2. SAML 判斷提示| IdP Browser -->|SAML 判斷提示| SP1 Browser -->|SAML 判斷提示| SP2 style IdP fill:#f96,stroke:#333,stroke-width:3px style Browser fill:#9cf,stroke:#333,stroke-width:2px
SAML 實務
SAML 成為企業 SSO 的標準：
✅ SAML 優勢
企業採用
- 主要 SaaS 供應商支援
- 跨組織邊界運作
- 成熟、廣為理解的協定
- 強大的安全屬性
使用案例
- 員工存取 SaaS 應用程式
- 合作夥伴聯合
- 客戶聯合（B2B）
- 學術聯合（Shibboleth）
組織部署 SAML 為員工提供對數十個 SaaS 應用程式的無縫存取。員工向企業 IdP（通常是 Active Directory Federation Services 或 Okta）進行一次身份驗證，然後存取 Salesforce、Workday、ServiceNow 和其他應用程式，無需額外登入。
SAML 限制
儘管廣泛採用，SAML 仍有限制：
🚫 SAML 挑戰
技術複雜性
- 基於 XML，冗長
- 複雜的設定
- 憑證管理開銷
- 難以除錯
行動裝置和 API 限制
- 專為基於瀏覽器的流程設計
- 行動應用支援差
- 不是為 API 授權設計
- 需要瀏覽器重新導向
SAML 適用於基於瀏覽器的企業應用程式，但在現代使用案例中遇到困難。行動應用無法輕鬆處理瀏覽器重新導向。API 需要無需使用者互動的授權。單頁應用程式需要 JSON，而不是 XML。這些限制為新協定創造了空間。
📖 深入了解：SAML
有關 SAML 架構、身份驗證流程、安全性最佳實務和實作指南的詳細內容，請參閱理解 SAML：企業聯合身份驗證詳解。
API 革命：OAuth
隨著 Web 應用程式演變為 API 驅動的架構，出現了一個新問題：如何在不共享密碼的情況下授予第三方應用程式對使用者資源的有限存取權限。
委派問題
在 OAuth 之前，應用程式使用密碼共享：
🚫 密碼反模式
問題
- 使用者將密碼提供給第三方應用
- 應用擁有帳戶的完全存取權限
- 無法在不變更密碼的情況下撤銷存取權限
- 密碼暴露給多方
範例
- 照片列印服務需要存取照片
- 使用者提供電子郵件密碼
- 服務下載所有電子郵件
- 服務儲存密碼
- 使用者無法選擇性撤銷存取權限
這種模式很常見但很危險。使用者與多個服務共享密碼，每個服務都獲得完全的帳戶存取權限。如果一個服務被攻破，所有服務都面臨風險。使用者無法在不變更密碼並更新所有服務的情況下撤銷對一個服務的存取權限。
OAuth 2.0 解決方案
OAuth 2.0 解決了委派問題：
🔑 OAuth 核心概念
實體
- 資源擁有者：擁有資料的使用者
- 客戶端：請求存取的應用程式
- 授權伺服器：頒發權杖
- 資源伺服器：託管受保護的資源
權杖
- 存取權杖：授予 API 存取權限
- 重新整理權杖：取得新的存取權杖
- 範圍：限制權限
- 過期：限時存取
關鍵原則
- 永不共享密碼
- 授予有限存取權限
- 可撤銷的權限
- 限時權杖
OAuth 實現了無需密碼共享的委派。當照片列印服務需要存取你的照片時，它會將你重新導向到照片服務的授權伺服器。你進行身份驗證並核准特定權限——「允許讀取照片」。授權伺服器向列印服務頒發存取權杖。此權杖授予有限存取權限（僅照片，不包括電子郵件）且時間有限。你可以隨時撤銷權杖，無需變更密碼。
OAuth 流程
OAuth 為不同場景定義了多種流程：
🔄 OAuth 授權類型
授權碼流程
- 用於帶後端的 Web 應用程式
- 最安全的流程
- 使用客戶端密鑰
- 建議用於機密客戶端
隱式流程
- 用於基於瀏覽器的應用（已棄用）
- 無客戶端密鑰
- URL 片段中的權杖
- 安全問題導致棄用
客戶端憑證流程
- 用於機器對機器
- 無使用者互動
- 服務帳戶身份驗證
- 後端服務
資源擁有者密碼流程
- 使用者向客戶端提供憑證
- 舊版遷移路徑
- 不建議
- 違背 OAuth 目的
授權碼流程是黃金標準。客戶端將使用者重新導向到授權伺服器，接收授權碼，然後使用其客戶端密鑰將該碼交換為存取權杖。此流程使權杖遠離瀏覽器並提供強大的安全性。
OAuth 實務
OAuth 變得無所不在：
✅ OAuth 採用
消費者應用程式
- 「使用 Google 登入」
- 「連接到 Facebook」
- 「授權 Twitter 存取」
- 第三方整合
API 授權
- 微服務身份驗證
- 行動應用後端存取
- 合作夥伴 API 存取
- IoT 裝置授權
OAuth 為網路上的「使用 Google 登入」按鈕提供支援。它使 Spotify 能夠發佈到 Facebook，健身應用能夠與健康平台同步，以及服務之間的無數整合。OAuth 的成功來自於用實用的解決方案解決真實問題——安全委派。
OAuth 限制
OAuth 解決了授權問題，但造成了身份驗證混淆：
🚫 OAuth 身份驗證混淆
OAuth 不是身份驗證
- OAuth 授予對資源的存取權限
- 不驗證使用者身分
- 存取權杖不識別使用者
- 使用 OAuth 進行身份驗證有風險
問題
- 開發人員誤用 OAuth 進行登入
- 出現安全漏洞
- 沒有標準的使用者資訊端點
- 實作不一致
開發人員看到 OAuth 的成功並嘗試將其用於身份驗證。他們會取得存取權杖並假設它識別了使用者。這造成了安全問題——存取權杖不是為證明身分而設計的。不同的提供者以不同的方式實作使用者資訊端點。生態系統需要在 OAuth 之上的標準身份驗證層。
現代 SSO：OpenID Connect
OpenID Connect（OIDC）基於 OAuth 2.0 建構，提供標準化的身份驗證。
OIDC 概覽
OpenID Connect 解決了 OAuth 未設計解決的身份驗證問題：
🆔 OIDC 核心創新
問題
- 開發人員誤用 OAuth 進行身份驗證
- 存取權杖不是身分證明
- 使用者資訊實作不一致
- 安全漏洞
OIDC 解決方案
- 向 OAuth 新增 ID 權杖（JWT）
- ID 權杖證明使用者身分
- 標準化使用者資訊
- 結合身份驗證 + 授權
關鍵優勢
- JSON 而不是 XML
- 行動裝置和 API 友善
- 簡單的開發者體驗
- 現代架構支援
OIDC 透過新增 ID 權杖擴展了 OAuth——一個包含身分宣告的 JWT。當你使用 OIDC 進行身份驗證時，你會同時收到 ID 權杖（證明你是誰）和存取權杖（授予 API 存取權限）。這種明確的分離消除了混淆並提供了安全的身份驗證。
Web/行動] AuthServer[授權伺服器
Auth0/Okta] API1[資源伺服器
使用者 API] API2[資源伺服器
支付 API] API3[資源伺服器
資料 API] User -->|登入| Client Client <-->|1. 身份驗證請求
2. ID 權杖 + 存取權杖| AuthServer Client -->|存取權杖| API1 Client -->|存取權杖| API2 Client -->|存取權杖| API3 API1 -.->|驗證權杖| AuthServer API2 -.->|驗證權杖| AuthServer API3 -.->|驗證權杖| AuthServer style AuthServer fill:#f96,stroke:#333,stroke-width:3px style Client fill:#9cf,stroke:#333,stroke-width:2px
OIDC 實務
OIDC 成為現代 SSO 標準：
✅ OIDC 採用
使用案例
- Web 應用程式登入
- 行動應用身份驗證
- API 授權
- 微服務安全
提供者
- Auth0、Okta、Azure AD
- Google Identity Platform
- AWS Cognito
- 自託管：Keycloak、ORY Hydra
OIDC 為跨 Web 應用、行動應用和 API 的現代身份驗證提供支援。開發人員使用標準函式庫進行整合，避免自訂身份驗證程式碼。
OIDC vs SAML
🎯 OIDC vs SAML 決策
選擇 SAML 當：
- 舊版企業應用整合
- 供應商僅支援 SAML
- 現有 SAML 基礎設施
選擇 OIDC 當：
- 建構新應用程式
- 行動應用身份驗證
- 需要 API 授權
- 現代架構
現實：
- 許多 IdP 同時支援兩者
- 新專案使用 OIDC
- 保留 SAML 用於舊版整合
SAML 不會消失，但新專案應該使用 OIDC。它更簡單、更靈活，更適合現代架構。
📖 深入了解：OpenID Connect
有關 OIDC 架構、身份驗證流程、ID 權杖、安全性最佳實務和實作指南的詳細內容，請參閱OpenID Connect：現代身份驗證詳解。
選擇正確的 SSO 技術
有多種 SSO 技術可用，如何選擇？
決策框架
使用此框架指導你的選擇：
🎯 SSO 技術選擇
Kerberos/WIA 適用於：
- 純 Windows 環境
- 企業網路存取
- 桌面應用程式
- 內網網站
- 無需外部存取
SPNEGO 適用於：
- 將 Kerberos 擴展到 Web
- 內網應用程式
- Windows 整合身份驗證
- 加入網域的裝置
SAML 適用於：
- 企業 SaaS 整合
- 供應商要求 SAML
- B2B 聯合
- 舊版應用程式支援
- 僅基於瀏覽器的流程
OAuth 適用於：
- API 授權
- 第三方整合
- 委派存取
- 不需要身份驗證
OIDC 適用於：
- 現代 Web 應用程式
- 行動應用程式
- API 授權 + 身份驗證
- 微服務
- 新開發
決策取決於你的環境。企業內網可能使用 Kerberos。企業 SaaS 整合使用 SAML。現代 Web 應用程式使用 OIDC。API 整合使用 OAuth。
常見錯誤
團隊在 SSO 方面犯了可預測的錯誤：
🚫 SSO 反模式
使用 OAuth 進行身份驗證
- OAuth 用於授權
- 不是為證明身分而設計
- 安全漏洞
- 改用 OIDC
實作自訂 SSO
- 「我們自己建構」
- 安全漏洞
- 維護負擔
- 使用標準協定
忽略權杖安全
- 在 localStorage 中儲存權杖
- 長期權杖
- 無權杖輪換
- 驗證不足
工作階段管理不當
- 無登出功能
- 工作階段固定漏洞
- 工作階段生命週期不一致
- 無單點登出
最常見的錯誤是使用 OAuth 進行身份驗證而不是 OIDC。開發人員看到 OAuth 的流行並嘗試使用存取權杖驗證使用者身分。這會造成安全問題。使用 OIDC 進行身份驗證——它是為此目的而設計的。
真實案例
看看組織如何實際實作 SSO 可以釐清差異：
企業內網：Kerberos
一家大型公司的內網使用 Kerberos：
🏢 企業內網
環境
- 10,000 名員工
- Windows 網域環境
- 內網應用程式
- 檔案共享和資料庫
- 桌面應用程式
實作
- Active Directory 作為 KDC
- Windows 整合身份驗證
- Web 應用程式的 SPNEGO
- 無縫桌面 SSO
- 無需額外登入
為何有效
- 同質 Windows 環境
- 企業網路存取
- 以桌面為中心的工作流程
- 現有 AD 基礎設施
- 對使用者透明
員工登入工作站一次。他們存取檔案共享、內網站點和桌面應用程式，無需額外身份驗證。Kerberos 透明地處理一切。這之所以有效，是因為環境受控——Windows 裝置、企業網路、受信任的應用程式。
SaaS 整合：SAML
一家企業整合 SaaS 應用程式使用 SAML：
☁️ SaaS 整合
環境
- 5,000 名員工
- 50+ SaaS 應用程式
- Salesforce、Workday、ServiceNow 等
- 需要集中存取控制
- 合規要求
實作
- Okta 作為 SAML IdP
- 與每個 SaaS 應用的 SAML 聯合
- 員工入口網站用於應用存取
- 集中配置
- 稽核日誌
為何有效
- SaaS 供應商支援 SAML
- 基於瀏覽器的應用程式
- 集中式身份驗證
- 簡化存取管理
- 滿足合規要求
員工向 Okta 進行一次身份驗證，然後存取所有 SaaS 應用程式，無需額外登入。IT 集中管理存取——配置新員工、取消配置離職員工、執行安全政策。SAML 實現了跨組織邊界的聯合。
現代 Web 應用：OIDC
一家新創公司建構 Web 應用程式使用 OIDC：
🚀 現代 Web 應用程式
環境
- 面向企業的 SaaS 產品
- Web 和行動應用程式
- RESTful API 後端
- 微服務架構
- 需要身份驗證和 API 授權
實作
- Auth0 作為 OIDC 提供者
- 帶 PKCE 的授權碼流程
- API 的 JWT 存取權杖
- 重新整理權杖輪換
- 標準 OIDC 函式庫
為何有效
- 現代架構
- 行動裝置和 Web 支援
- 內建 API 授權
- 開發者友善
- 安全最佳實務
使用者使用 OIDC 進行身份驗證，接收 ID 權杖和存取權杖。Web 應用驗證 ID 權杖進行身份驗證。行動應用使用存取權杖進行 API 呼叫。微服務驗證 JWT 權杖。OIDC 在一個協定中提供身份驗證和授權，完美適合現代架構。
安全考量
SSO 提高了安全性，但也引入了新風險：
權杖安全
權杖需要小心處理：
⚠️ 權杖安全最佳實務
儲存
- 永不在 localStorage 中儲存權杖
- 儘可能使用 httpOnly cookie
- 靜態加密權杖
- 登出時清除權杖
傳輸
- 始終使用 HTTPS
- 驗證 TLS 憑證
- 避免在 URL 中使用權杖
- 使用安全標頭
驗證
- 驗證權杖簽章
- 檢查過期時間
- 驗證頒發者
- 驗證受眾
輪換
- 短期存取權杖
- 重新整理權杖輪換
- 撤銷機制
- 監控濫用
權杖是持有者憑證——任何擁有權杖的人都可以使用它。在 localStorage 中儲存權杖會使其暴露於 XSS 攻擊。長期權杖在被攻破時會增加風險。始終正確驗證權杖——檢查簽章、過期時間、頒發者和受眾。
單點故障
SSO 建立了單點故障：
⚠️ SSO 可用性風險
問題
- IdP 中斷阻止所有存取
- 無後備身份驗證
- 業務持續性風險
- 依賴外部服務
緩解
- 高可用性 IdP 部署
- 災難復原計畫
- 緊急存取程序
- SLA 監控
- 考慮多 IdP 設定
當你的 IdP 當機時，使用者無法存取任何內容。這使得 IdP 可用性至關重要。部署具有高可用性的 IdP，規劃災難，並建立緊急存取程序。一些組織部署多個 IdP 以實現冗餘。
工作階段管理
SSO 使工作階段管理複雜化：
⚠️ 工作階段管理挑戰
多個工作階段
- IdP 工作階段
- 應用程式工作階段
- 不同的生命週期
- 登出複雜性
單點登出
- 從一個應用登出
- 應該從所有應用登出
- 需要協調
- 通常不完整
最佳實務
- 實作單點登出
- 一致的工作階段生命週期
- 瀏覽器關閉時清除工作階段
- 監控活動工作階段
使用者期望從一個應用程式登出會從所有應用程式登出。實作這一點需要 IdP 和所有應用程式之間的協調。許多 SSO 實作處理登入很好，但登出很差，在使用者認為已登出後仍保持工作階段活動。
結論
單點登入在三十年間從企業網路身份驗證演變為雲原生協定。Kerberos 在 1980 年代提供了安全的網路身份驗證。Windows 整合身份驗證將其擴展到桌面環境。SPNEGO 將 Windows 身份驗證橋接到 Web 瀏覽器。SAML 實現了跨組織邊界的企業聯合。OAuth 解決了 API 授權和委派。OpenID Connect 統一了現代應用程式的身份驗證和授權。
每種技術都是為了解決特定環境中的特定問題而出現的。Kerberos 適用於具有 Windows 基礎設施的企業網路。SAML 適用於具有基於瀏覽器流程的企業 SaaS 整合。OAuth 適用於 API 授權和第三方整合。OIDC 適用於需要身份驗證和授權的現代 Web 和行動應用程式。
常見錯誤包括使用 OAuth 進行身份驗證而不是 OIDC、實作自訂 SSO 而不是使用標準協定、權杖安全實務不當以及工作階段管理不足。這些錯誤會危及安全性並造成維護負擔。
SSO 技術之間的決策取決於你的環境。企業內網使用 Kerberos。企業 SaaS 整合使用 SAML。現代 Web 應用程式使用 OIDC。API 整合使用 OAuth。許多組織使用多種協定——對舊版應用程式使用 SAML，對新開發使用 OIDC。
安全考量包括權杖安全、單點故障風險和工作階段管理複雜性。權杖需要小心儲存、傳輸、驗證和輪換。SSO 建立了需要緩解的可用性依賴關係。跨多個應用程式的工作階段管理需要協調。
真實案例顯示 Kerberos 在企業內網中成功、SAML 在企業 SaaS 整合中成功、OIDC 在現代 Web 應用程式中成功。每種技術在其適當的環境中都表現出色。
在選擇 SSO 技術之前，了解你的需求。你有什麼類型的應用程式？使用者在哪裡存取它們？存在哪些安全要求？已經存在什麼基礎設施？這些問題的答案比關於哪種協定更好的意見更重要。
目標不是完美遵守一種協定。目標是實現業務目標的安全、可用的身份驗證。將協定用作工具，而不是目標。根據你的環境進行選擇，實施安全最佳實務，並專注於使用者體驗。
無論你選擇 Kerberos、SAML、OAuth 還是 OIDC，請記住：SSO 是解決身份驗證問題的工具，而不是目的本身。專注於結果——安全存取、良好的使用者體驗、營運效率。如果協定有助於實現這些結果，就使用它。如果沒有，就選擇不同的。這才是良好安全架構的真正意義。