SSO 與 SAML，為所有人解釋

SSO 和 SAML 經常被含糊地使用，可以被解釋為不同的方式。在本文中，我們將澄清這些概念，解釋它們之間的關係，並提供實際例子以幫助更容易理解。

什麼是 SSO？#

SSO（單一登錄）是一種身份驗證流程，允許用戶一次登錄後即可訪問多個應用程式或服務，而無需重新登錄到每個應用程式。不過，這個通用定義可以適用於 SSO 使用的不同場景。

有多種場景中，SSO 會派上用場。

社交 SSO#

有時，人們將社交登入稱為社交 SSO。例如，用戶可以使用 Google 登錄來在新的應用程式中創建賬號，直接使用存儲在 Google 中的身份和信息。在此場景中，用戶管理自己的身份。

社交 SSO 讓用戶更容易控制自己的信息，減少賬號創建和登錄過程中的繁瑣步驟。社交 SSO 通常依賴於開放標準協議，例如 OAuth 2.0 和 OIDC。

企業 SSO#

首先，我們用簡單的術語解析 Identity Provider 和 Service Provider 的概念。

1. 身份提供者 (IdP) 就像是你身份的“守門人”。它是保存你的登錄信息並驗證你身份的系統。可以將其視為一個信任的權威，說道：“是的，這個人就是他們所聲稱的那個人。” 例如有 Google Workspace、Microsoft Entra 和 Okta Workforce Identity。
2. 服務提供者 (SP) 是你一旦身份驗證後想要訪問的“應用程式”或“服務”。這是你嘗試登錄的地方，比如一個應用程式或網站。例如 Zoom、Slack，或者你公司的內部工具都是服務提供者。

簡單來說，身份提供者證明你是誰，服務提供者在你的身份被確認後給予你訪問其服務的權限。

企業 SSO 用於更多以業務為重點的場景，並按照上述兩個術語劃分，有兩個典型案例：IdP 發起的 SSO 和 SP 發起的 SSO。儘管這些術語聽起來很技術性，但場景其實是相當簡單的。

IdP 發起的 SSO#

考慮一下，當你作為一名員工加入公司應用程式和資源的時候。通常，人力資源部會為你創建一個帳號。然後你使用該帳號登錄到一個平台，如 Okta 或 Google Workspace。一旦登錄，你將被引導到公司門戶，你可以訪問公司的所有應用程式，如工資系統、協作工具、Workday 等。

SP 發起的 SSO#

讓我們換個角度來看。有時，你需要從一個特定產品的登錄頁面開始。例如，如果你想使用 Zoom 與同事進行線上會議，你將看到一個選項“使用 SSO 登錄”。這個場景稱為 SP 發起的 SSO。

企業 SSO 解決了什麼問題#

企業 SSO 的首要好處是能讓企業輕鬆、靈活和安全地管理員工身份。

假設你經營一家公司，所有員工都需要訪問你購買的產品和服務。由於公司生產的資源屬於公司，需要一個公司所有的身份系統。如果員工使用個人身份訪問公司資源，將會引發安全和管理上的挑戰。

另一方面，在像 SP 發起的 SSO 這樣的場景中，員工可以訪問公司擁有的多個應用程式和服務。當員工加入或離開公司時，人力資源部需要為公司所有的產品和服務創建和刪除眾多帳號，這既繁瑣又耗時。

企業 SSO 通過一個通用身份系統簡化了這個過程，工具如 SCIM（跨域身份管理系統）和 實時供應 使它更有效率。

對於 IdP 發起的 SSO，這對於想要成為“企業準備好”的產品建設者是有益的。例如，如果你是一家最初專注於個人消費者的初創公司，稍後一個大企業想要使用你的產品，他們可能要求員工使用 Microsoft Entra 登錄。例如，在這種情況下，你需要將企業 SSO 整合到你的產品中以完成交易。

什麼是 SAML？#

SAML（安全斷言標記語言） 是一種用於身份驗證和授權的開放標準協議。與 OAuth 和 OIDC 一樣，SAML 被廣泛用於身份管理系統中，特別是在員工身份管理中。商業身份提供者如 Okta 和 Microsoft Entra 通常支持 SAML 作為其標準協議之一。

一些較舊的系統和社交登錄提供者也提供 SAML 支持，因此在你的系統中內置 SAML 可以幫助確保與更廣泛的身份提供者兼容性和未來生態系統增長。

什麼時候需要 SAML？#

SAML 經常在 企業 SSO 場景中使用。例如，考慮這種情況：

你的銷售團隊告訴產品開發者，“我們有一個大客戶，他們需要 SAML 登錄。我們需要支持這項技術。”

對於不熟悉 SAML 或 IAM（身份和訪問管理） 的工程師來說，他們的第一步可能是搜索“SAML”或“SAML 登錄”。

最終目的是將企業 SSO 整合到你的產品中，使其“企業準備好”，以滿足那些依賴 SAML 等技術進行安全身份驗證的大客戶的需求。

SAML 如何運作#

以下是兩種類型的簡化分解：

SP 發起的流程#

1. 用戶嘗試訪問 SP 的資源。
2. SP 將用戶重定向到 IdP，帶有 SAML 身份驗證請求。
3. 用戶在 IdP 登錄並被驗證。
4. IdP 生成一個帶有用戶身份和可能的授權數據的 SAML 斷言。
5. IdP 通常透過用戶的瀏覽器將 SAML 斷言發回 SP。
6. SP 處理該斷言，驗證它，並允許/拒絕用戶訪問。

IdP 發起的流程#

1. 用戶已登錄到 IdP，從 IdP 的門戶中選擇一個服務/資源。
2. IdP 根據用戶當前的會話生成一個帶有身份和屬性的 SAML 斷言。
3. IdP 將該斷言直接發送到 SP，而不用提前請求 SP。
4. SP 處理該斷言，驗證其完整性，並提取用戶的身份和屬性。
5. SP 根據該斷言允許或拒絕訪問。

要了解 SAML 如何從技術角度運作，請查看 SAML 如何運作

SAML 和 SSO 的區別#

SAML 和 SSO 的定義經常被混淆，但這是簡單的分解：

1. SSO 是應用程式和軟件使用的身份驗證過程，允許用戶一次登錄後即可訪問多個服務。
2. SAML 是一種主要用於企業身份管理的技術協議，安全地交換身份驗證數據。

想像一下：你早上走進辦公室，而不是分別登錄每個應用程式——你的電子郵件、日曆、項目管理工具——你只是一次登錄即可訪問所有內容。這種無縫的體驗就是 SSO（單一登錄）。就像擁有一把通用鑰匙，可以打開你工作場所所有工具的門。

那麼，SSO 是如何運作的呢？

這就是 SAML（安全斷言標記語言）發揮作用的地方。可以把 SAML 想像成你的登錄系統（稱為身份提供者，或 IdP）和你想使用的應用程式（稱為服務提供者，或 SPs）之間的信任信使。當你通過 SSO 登錄時，SAML 安全地從 IdP 向應用程式發送一個你的身份的“證明”，確認你是你所說的那個人。

所以，簡而言之：

1. SSO 是一種用戶體驗：一次登錄即可訪問多個應用程式。
2. SAML 是在幕後讓這種無縫體驗成為可能的協議，安全地處理身份驗證。

雖然 SSO 提升了便利性，SAML 確保了一切保持安全和連接，讓你可以毫不費力地訪問所有內容。

企業 SSO 是否使用其他協議？#

是的，除了 SAML，OIDC 是在企業 SSO 場景中常用的另一個協議。例如，在 Logto 的企業連接器中，它支持 Microsoft Entra（OIDC）和 Microsoft Entra（SAML）。

我應該使用 SAML SSO 嗎？#

如果你正在向企業客戶銷售產品，那麼考慮越早支持 SAML 就越重要。但不要僅僅專注於支持 SAML 協議——考慮整個企業 SSO 認證流程。以下是幾個關鍵場景需要考慮：

1. 允許你的客戶自助註冊和設置企業 SSO。
2. 確保員工可以自動加入 多租戶 應用程式中的正確機構（這可以通過實時供應和 SCIM 完成）。
3. 實現一個與面向消費者的登錄流程兼容的端到端登錄流程。

使用 Logto 實現 SAML 和企業 SSO#

Logto 提供端到端的 企業 SSO 流程 並支持多個知名的 SAML 連接器。它可以整合到許多常見的場景中且你會需要。探索 Logto 的所有功能，從 Logto Cloud 到 Logto OSS，請訪問 Logto 網站。