這篇文章一起來看看「當使用者使用 SSO 登入後，背後系統發生的事情」。如果你在軟體業工作，下次可以留意自家公司是使用哪一種方式來實作，能對產品的背後運作更加了解

上篇文章 講完了 SSO 是什麼、SSO 的兩種設計協定後，這篇文章一起來看看「當使用者使用 SSO 登入後，背後系統發生的事情」。

以 SAML 為例，看 SSO 的運作方式

當使用者登入 Gmail 時，背後實際上發生了

1. 輸入組織的的 Gmail，例如 chichu@pmstoolbox.com
2. Gmail Server 發現使用者使用「企業 Google 帳號」登入，對使用者的瀏覽器發出 SAR (SAML Authentication Request，SAML 授權請求)
3. 使用者的瀏覽器被轉址 (redirect) 到「身分提供商 (Identity Provider)」網站 ，例如 Okta, Auth0, onelogin…等
4. 身分提供商在使用者的瀏覽器介面上顯示登入頁面 (帳號/密碼)，使用者輸入帳號/密碼
5. 使用者的瀏覽器將加密後的帳號/密碼送回至身分提供商
6. 身分提供商產生「簽署核可的 SAML 聲明 (Signed SAML assertion)」，並送回至使用者瀏覽器
7. 瀏覽器將「簽署核可的 SAML 聲明」送至 Gmail
8. Gmail 驗證「簽署核可的 SAML 聲明」來自企業使用的身分提供商
9. Gmail 返回受保護的內容 (例如使用者的郵件內容)

PS. SAML 聲明 (SAML assertion)是一個經過加密簽署的 XML 文件，內容包含 (1) 使用者資訊 (2) 使用者能夠取用的服務。

來看使用者登入 SSO 之後，瀏覽其他應用程式的流程

當使用者登入 workday (Service Provider)時，背後實際上發生了

1. 使用者在 workday 的登入頁面上，輸入 chichu@pmstoolbox.com
2. workday 頁面對使用者的瀏覽器發出 SAR (SAML Authentication Request)
3. 使用者的瀏覽器被導流至 (redirect) 身分提供商 (Identity Provider) ，例如 Okta, Auth0, onelogin…等
4. 因為使用者已經登入 SSO，因此跳過登入步驟。身分提供商產生「簽署核可的 SAML 聲明 (Signed SAML assertion)」
5. 身分提供商將「「簽署核可的 SAML 聲明」送回至使用者瀏覽器
6. 瀏覽器將「簽署核可的 SAML 聲明」送至 workday (Service Provider)
7. workday 驗證「簽署核可的 SAML 聲明」來自企業使用的身分提供商 (Identity Provider)
8. workday 允許使用者使用服務

SAML 和 OpenID 的差異，工程團隊如何選？

這兩者的實作細節有差異，但大觀念是類似的。

兩者

• 都有經過加密
• 多數 Identity Provider 兩者都有支援

因此工程團隊在選擇時，主要是考量到協定與串接上所需的工來決定的。

如果你在軟體業工作，下次可以留意自家公司是使用哪一種方式來實作，能對產品的背後運作更加了解。

這篇文章 為什麼多數網站都可以一鍵登入？解釋背後技術 SSO 的流程 ｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。