今天是第22天，辛苦每一位閱讀到這裡的夥伴，應該要給自己一點掌聲！

學習到這裡，我們已經學會以下內容：

• Day 17–18：OAuth 的角色與授權碼流程。
• Day 19–20：OIDC 如何在 OAuth 上加上「身分層」，並完成 Google 登入。
• Day 21：SAML 的基礎觀念與流程。

今天，我們就把 SAML 與 OIDC 放在一起比較，來理解什麼時候用 SAML，什麼時候用 OIDC？

簡單來說，這兩個功能可以這樣區分。

• SAML：企業界的傳統標準，基於 XML，適合 大型企業 SSO。
• OIDC：現代化的登入協定，基於 JSON/JWT，適合 Web 與行動應用。

技術的部分也可以分成這些：

技術比較表

SAML與OIDC流程差異

• SAML：

  使用者 → Service Provider (SP) → 重導到 IdP → 登入 → IdP 生成 SAML Response（XML Assertion） → 透過瀏覽器 POST 回 SP → 驗證 XML 簽章 → 登入成功。

• OIDC：

  使用者 → Client → 重導到 Authorization Server → 登入 → 回傳 code → Client 用 code 換取 Access Token + ID Token (JWT) → 驗證 ID Token → 登入成功。

SAML 帶回的是 XML，OIDC 帶回的是 JWT。

應用場景比較

接下來就是最重要的使用情境，我們根據不同的使用需求進行以下區分：

1. SAML
   • 你的客戶是企業，已經有 IdP（如 Okta、ADFS、Azure AD）。
   • 需要整合舊系統（SAP、Oracle、Jira…）。
   • 強調 Portal/SSO：一次登入，進入公司內部所有系統。
2. OIDC
   • 你的服務面向一般使用者，需要「用 Google/LINE/Facebook 登入」。
   • 你的應用是行動 App、SPA，需要 JSON API 友好格式。
   • 需要同時處理「認證」與「授權」（因為基於 OAuth）。

假設你要開發一個 SaaS 平台：

• 如果你要賣給一般大眾 → 使用者習慣用 Google 登入 → 選 OIDC。
• 如果你要賣給大型企業 → 他們希望員工用公司帳號登入（Okta/AD） → 只能支援 SAML。

很多 SaaS 公司最後會 同時支援 SAML 與 OIDC，以滿足不同市場需求。

除了使用需求比較之外，當然還是要比較一下安全需求：

安全比較

• SAML：風險多在 XML 簽章驗證 與 Replay Attack。
• OIDC：重點在 驗證 ID Token（iss/aud/exp/nonce） 與 Token 保護。

但無論是SAML或者是OIDC，兩者都必須強制走 HTTPS，避免攔截攻擊。

今天我們比較了 SAML vs OIDC：

• 技術面：SAML 是 XML / OIDC 是 JSON。
• 應用場景：SAML 偏向企業內部 SSO，OIDC 偏向現代 SaaS 與行動應用。
• 趨勢：新專案多選 OIDC，但 SAML 在企業內仍會長期存在。

今天的教學就到這裡，讓我們明天見囉！