經歷了前幾天設定「條件式存取」與「無密碼登入」的實戰洗禮後，今天我們要來面對公會裡另一個巨大的維運災難：「村民們每天要登入幾十個不同的系統（信箱、ERP、請假系統、雲端硬碟），難道要讓他們硬記幾十組密碼嗎？」
這不僅是使用者的惡夢，更是資安魔導團眼中的巨大漏洞，因為當密碼太多時，大多數村民會選擇把密碼寫在便利貼上，大剌剌地貼在螢幕旁邊，或者是所有系統都用同一組「萬年密碼」，這時我們就需要祭出身份驗證領域的救星：單一登入 (Single Sign-On, SSO)。

今天，就讓我們一起來搞懂 SSO 世界裡最核心的兩大通訊協定——SAML 與 OAuth 2.0（及 OIDC）的基礎觀念！

• 什麼是單一登入 (SSO)？
  在傳統的村莊架構下，每一個應用程式（例如公會的佈告欄、請假系統）都有自己的帳號密碼資料庫，而在 SSO 架構下，所有的應用程式都不再自己驗證密碼了，而是通通把驗證的工作「外包」給一個絕對信任的身分識別提供者 (Identity Provider, 簡稱 IdP)——在我們的世界裡，這個 IdP 就是你手上的 Entra ID。
  當應用程式需要驗證身分時，它們之間的對話，就是透過標準的通訊協定來進行，也就是接下來要介紹的 SAML 與 OAuth 2.0 / OIDC。

1. 企業界的老大哥：SAML 2.0
   SAML (Security Assertion Markup Language)專門為了企業級的Web應用程式打造的SSO協定，歷史悠久、成熟，至今仍是多數傳統企業軟體的首選。

• 核心角色
  • 身分提供者(Identity Provider)： 負責驗證「你是誰」（如我們的 Entra ID）。
  • 服務提供者 (Service Provider)： 你想登入的應用程式 (如公會的 ERP 系統)。
• 生活化的比喻： 就像你去考駕照，監理所 (IdP) 查驗了你的身分證和考試成績後，發給你一張駕照，你拿著駕照去租車行 (SP)，雖然租車行的老闆根本不認識你，但他認得監理所的鋼印，看到駕照就安心把車租給你。
• 技術特徵：它使用 XML 格式來傳遞資料，而這份夾帶身分證明的通關文件，在 SAML 的世界裡被稱為 Assertion (宣告)。

2. 現代 Web 與 API 的標準：OAuth 2.0 與 OIDC
   隨著行動裝置和 API 的興起，SAML 顯得有些笨重，於是誕生了輕量級的 OAuth 2.0。

• OAuth 2.0 不是用來「身分驗證」的
  這是一個常見的誤解！OAuth 2.0 其實是一個「授權 (Authorization)」協定，它的目的是：「在不給出密碼的情況下，允許某個 App 存取你在另一個網站的資料」。
  • 生活化的比喻： 就像你去住高級飯店，給了代客泊車小弟一把「只能開車門和發動引擎，但打不開後車廂」的泊車鑰匙 (Access Token)，他能把你的車開去停（取得授權），但他不知道你家住哪，也看不到後車廂裡的私人物品（沒有取得你的身分資料）。
• 加上身分證的 OpenID Connect (OIDC)
  為了解決 OAuth 2.0 無法驗證「你是誰」的問題，現代技術在 OAuth 2.0 的基礎上加了一層 OIDC，OIDC 會在發放授權鑰匙 (Access Token) 的同時，額外發放一張專屬的身分證 (ID Token)，這就是為什麼我們現在常在網路上看到「使用 Google / Microsoft / Apple 帳號登入」，背後跑的幾乎全都是 OIDC 協定！
• 專為了現代網頁、手機APP設計，使用輕量化的Jason格式傳遞資料。