到目前為止，我們已經看過 OAuth2（授權） 與 OIDC（認證）。今天，我們要認識另一個「身分驗證標準」：SAML（Security Assertion Markup Language）。

它是許多企業在做 SSO（Single Sign-On，單一登入） 的時候常用的技術。

什麼是 SAML？

• 全名：Security Assertion Markup Language。
• 格式：基於 XML 的協定（不像 OIDC 使用 JSON）。
• 核心用途：在不同網域之間傳遞「身分斷言（Assertion）」—— 也就是「某某人已經在某個系統中被認證過了」。
• 典型場景：企業員工在內部入口網站登入一次，就能無縫進入 Gmail、Salesforce、Jira、SAP… 等外部 SaaS。

三個角色

SAML 的角色與 OAuth/OIDC 不同，但概念上可以對照：

SAML Assertion

SAML 的核心是 Assertion（斷言）：一段 XML，通常包含：

• Authentication Statement（已通過驗證）
• Attribute Statement（使用者屬性，如姓名、Email、部門）
• Authorization Decision Statement（可選，用於描述是否有權存取某資源）

這份斷言由 IdP 簽名（XML Signature），交給 SP，讓 SP 確認「這個人確實已經登入過」。

SAML 流程

整體來說SAML有許多建立的流程，目前最常見的是 Web Browser SSO Profile：

1. 使用者存取 SP

   • 使用者打開 Salesforce（SP），但尚未登入。

2. SP 轉送到 IdP

   • SP 產生一個 SAML AuthnRequest（XML 格式），透過瀏覽器轉送到 IdP。

3. IdP 驗證使用者

   • IdP（例如 Okta）檢查使用者是否已經登入，若沒有則要求登入。

4. IdP 回傳 Assertion

   • 驗證成功後，IdP 生成一份 SAML Response（內含 Assertion，通常 Base64 編碼），透過瀏覽器 POST 回 SP 的 Assertion Consumer Service (ACS) URL。

5. SP 驗證 Assertion

   • SP 使用 IdP 的公開金鑰驗證 XML 簽章，確認合法。
   • 驗證成功後，建立本地 Session，使用者完成登入。

   與 OAuth/OIDC 的「Redirect + Token」不同，SAML 主要透過 瀏覽器 POST XML 來回傳訊息。

SAML vs OIDC 比較

簡單說：

• 如果你在做 企業內部系統整合 → 常見 SAML。
• 如果你在做 Web / App 登入 → 常見 OIDC。

小劇場案例

假設你的公司用 Okta 當 IdP，並且買了 Salesforce 作為 CRM：

• 員工先登入公司入口網站（Okta）。
• 員工點擊 Salesforce → Okta 生成一份 SAML Assertion，證明「這個人已經登入，Email 為 user@company.com」。
• Salesforce 驗證 Assertion，直接把員工導入首頁，不用再輸入密碼。

SAML 也有風險

• XML 簽章攻擊（XML Signature Wrapping）：必須正確驗證簽章與結構，否則可能被注入。
• Replay Attack：SAML Response 需要設置有效時間（NotBefore/NotOnOrAfter）。
• 傳輸安全：必須強制使用 HTTPS，避免 Assertion 被攔截。

小結

今天我們認識了 SAML：

• 它是基於 XML 的身分驗證標準，常用於 企業 SSO。
• 三個角色：Principal（使用者）、IdP、SP。
• 核心是 Assertion（斷言），由 IdP 簽名後交給 SP。
• 與 OIDC 相比：SAML 偏向企業、XML 格式較重；OIDC 偏向 Web/App，使用 JSON/JWT 更輕量。

明天，我們將進一步探討 Spring Security 整合 SAML 的觀念，看看如何在 Spring Boot 中讓應用成為 SAML 的 Service Provider。

我們明天見！