IdP 發起的 SSO 與 SP 發起的 SSO#

術語#

• 身份提供者 (IdP)：存儲和驗證用戶身份的服務。
• 服務提供者 (SP)：為用戶提供服務的網站或服務。
• 單一登入 (SSO)：允許用戶使用一組登入憑據（例如，名稱和密碼）訪問多個應用程式的會話和用戶驗證服務。
• SAML：安全聲明標記語言是一種開放標準，用於在各方之間，特別是在身份提供者和服務提供者之間交換驗證和授權資料。這是 SSO 常用的協議。一旦用戶成功由 IdP 驗證，IdP 會向 SP 發送 SAML 聲明，SP 驗證後授予用戶訪問權限。
• OIDC：OpenID Connect 是一種更現代且安全的 SSO 協議。它建立在 OAuth 2.0 之上，提供了一種基於 IdP 執行的驗證來驗證用戶身份的方法。一旦用戶成功由 IdP 驗證，IdP 會向 SP 發送一個 JWT 格式的令牌，SP 驗證後授予用戶訪問權限。

SP 發起的 SSO#

顧名思義，SP 發起的 SSO 由服務提供者發起。用戶通過訪問 SP 網站上的資源來開始驗證過程。然後 SP 將用戶重定向到 IdP 以進行驗證。一旦用戶驗證成功，IdP 生成一個令牌（OIDC）或一個 SAML 聲明（SAML）並將其發送回 SP。SP 驗證該令牌或聲明，並授予用戶訪問權限。

1. 用戶訪問 SP 的網站並嘗試訪問一個資源。
2. 用戶點擊 SSO 提供者的登入按鈕（例如，Google、Azure AD、Okta 等）。
3. SP 將用戶重定向到 IdP 進行驗證。
4. 用戶登入到 IdP。
5. IdP 向 SP 發送一個令牌或聲明。
6. SP 驗證該令牌或聲明，並授予用戶訪問權限。

IdP 發起的 SSO#

與 SP 發起的 SSO 不同，IdP 發起的 SSO 是由身份提供者發起的。用戶從 IdP 的網站開始驗證過程。通常，用戶會在 IdP 的入口網站上找到支持的 SP 應用程式列表。用戶點擊 SP 應用程式，然後使用預先驗證的身份重定向到 SP 的網站。

1. 用戶登入到 IdP。
2. 用戶訪問 IdP 的入口網站並選擇一個 SP 應用程式。
3. IdP 驗證用戶的當前會話並將用戶重定向到 SP，使用預先驗證的 SSO 身份。
4. SP 驗證 SSO 身份並授予用戶訪問權限。

IdP 發起的 SSO 與 SP 發起的 SSO#

IdP 發起的 SSO 相較於 SP 發起的 SSO 的優勢#

IdP 發起的 SSO 在依賴各種第三方應用程式或服務的大型企業和組織中更為常用。例如 Workday、Salesforce 等。它提供了一種集中式的方法來管理多個應用程式的用戶訪問並加強 SSO 驗證。通過啟用 IdP 發起的 SSO，員工可以直接從 IdP 的入口網站訪問連接的應用程式，而不需訪問每個應用程式的網站，減少入職時間並改善用戶體驗。

IdP 發起的 SSO 相較於 SP 發起的 SSO 的風險#

IdP 發起的 SSO 比 SP 發起的 SSO 承擔更多風險。

1. 缺乏驗證上下文：所有從 IdP 發起的驗證請求都是未經請求的。因此，SP 發起驗證過程，可能會打開未經授權訪問的門戶。有用戶的會話被劫持的風險。惡意行為者可能在用戶不知情或未經同意的情況下為合法用戶發起登入過程。

2. 會話固定：由於 SP 不發起驗證過程，用戶的會話可能會被固定到 IdP 的會話。這可能導致會話固定攻击，攻擊者可能會固定用戶的會話到 IdP 的會話，並獲得未經授權的訪問。

3. 釣魚攻擊：IdP 發起的 SSO 可能容易受到釣魚攻擊。惡意行為者可能會誘騙用戶訪問假冒的 IdP 入口網站並竊取用戶的憑據。一旦用戶登入，攻擊者可能會使用預先驗證的身份將用戶重定向到 SP。

4. 未對請求驗證提供保證：在 SP 發起的 SSO 中，通常 SP 會在向 IdP 發送的請求中包含必要的安全資訊以維護請求的完整性。一旦 SP 收到驗證回應，它將驗證這些資訊以防止任何 CSRF 攻擊。例子包括 OIDC 中的 state 參數和 SAML 中的 RelayState。然而，在 IdP 發起的 SSO 中，SP 不發起驗證過程，因此 SP 無法對請求的驗證提供任何保證。

IdP 發起的 SSO 相較於 SP 發起的 SSO 的限制#

由於上述漏洞，OIDC 不支持IdP 發起的 SSO。OIDC 要求 SP 發起驗證過程以確保請求的完整性。即使在用戶從第三方而非 SP 開始驗證過程的時候，也應首先將用戶定向到 SP 以發起驗證過程。

但在 SAML 中，IdP 發起的 SSO 是可能的。IdP 可以生成 SAML 聲明而不需要 SP 發起驗證過程。在 SAML IdP 發起的 SSO 中，沒有適當的 RequestID 和 RelayState 的 SAML 聲明可能會直接發送到 SP 的 ACS URL。SP 應能處理這種類型的聲明並授予用戶訪問權限。（注意：沒有 RequestID 和 RelayState 的情況下，SP 對請求的完整性沒有保證）。

結論#

即使 IdP 發起的 SSO 提供了一種集中管理多個應用程式的用戶訪問的方法，但相比起 SP 發起的 SSO，它承擔更多的風險。SP 發起的 SSO 更安全並對驗證請求的完整性提供更多保証。建議對 OIDC 和 SAML 基於 SSO 使用 SP 發起的 SSO。