在一篇文章中了解 IAM、OAuth、OpenID Connect、SAML、SSO 和 JWT

身份和存取管理 (IAM) 的領域在最近幾年變得更加複雜。像 OAuth、OpenID Connect (OIDC)、SAML、SSO 和 JWT 這樣的專業術語經常被使用，但它們到底是什麼意思？它們如何協同工作？讓我們一起探討這些概念和框架，使它們更易理解和實用。

什麼是 IAM？#

身份和存取管理 (IAM) 是一個廣泛的概念，涉及管理數位 身份 和實施 存取控制。之前提到的框架和協定屬於 IAM，每個都針對這個領域的特定挑戰。

本質上，IAM 是關於：

• 身份：用戶、服務或設備的數位表示。身份通常包括名稱、電子郵件、角色等屬性，以描述這個實體。
• 存取：與資源互動、執行操作或使用服務的能力。存取定義了可以對哪些資源執行什麼動作。

在上面的圖中，用戶 (身份) 想要在 API (資源) 上執行 GET 請求。用戶的屬性 - 名稱、電子郵件和角色 - 描述了這個身份。

驗證與授權#

驗證和授權經常在 IAM 討論中共同出現。讓我們來澄清它們的定義：

• 驗證：確認擁有身份的過程。它回答了問題：「你擁有哪個身份？」
• 授權：決定已驗證的身份可以對資源執行什麼動作的過程。它回答了問題：「你可以做什麼？」

在前面的例子中：

• 在用戶 (身份) 可以執行任何操作之前，他們必須完成 驗證 過程。
• 驗證之後，系統需要確定該用戶是否可以在 API (資源) 上執行 GET 請求 (動作)，即完成 授權 過程。

---

掌握了這些基礎知識後，讓我們解密其他的縮寫和協定。

OAuth#

OAuth 2.0，通常簡稱為 OAuth，是一個 授權 框架，允許應用程式代表用戶訪問另一個應用程式上的受保護資源。

比如，想像你有一個名為 MyApp 的網頁應用程式，它想要存取用戶的 Google 雲端硬碟。MyApp 不需要要求用戶分享他們的 Google 雲端硬碟登入憑證，而是可以使用 OAuth 2.0 從 Google 獲得對用戶硬碟的存取許可 (授權)。

這裡有一個簡化的 OAuth 流程圖：

在此流程中：

• MyApp 是請求存取 Google 雲端硬碟 (資源) 的客戶端 (身份)。
• 用戶 (資源擁有者) 在第 6 步授予 MyApp 許可，完成 授權 過程。

OAuth 2.0 的關鍵要素之一是 訪問令牌，客戶端用它來證明用戶對資源的授權。要深入了解，請參見 訪問令牌。

OpenID Connect (OIDC)#

OpenID Connect (OIDC) 是構建在 OAuth 2.0 之上的 驗證 層。它增加了專門用於驗證的功能，比如 ID 令牌 和一個 UserInfo 端點，使其適合於驗證與授權。

如果我們重訪 OAuth 流程，加入 OIDC 會引入一個 ID 令牌。該令牌包含被驗證用戶的資訊，並使 MyApp 能夠驗證用戶的身份。

示例情境：「使用 Google 登入」#

讓我們換個例子。如果 MyApp 想讓用戶使用他們的 Google 帳號登入，目標就從資源的存取轉變為身份驗證。在這種情況下，OIDC 是一個更合適的選擇。以下是 OIDC 流程的樣子：

主要區別：除了訪問令牌，OIDC 還提供一個 ID 令牌，這讓 MyApp 可以在不需要額外請求的情況下驗證用戶。

OIDC 分享 OAuth 2.0 的 授權方式 定義，確保這兩個框架之間的兼容性和一致性。

SAML#

安全聲明標記語言 (SAML) 是一種基於 XML 的框架，用於在各方之間交換 驗證 和 授權 資料。SAML 於 2000 年代初推出，已在企業環境中廣泛採用。

SAML 與 OIDC 比較#

SAML 和 OIDC 在功能上相似，但在實現細節上有所不同：

• SAML：使用基於 XML 的聲明，通常被認為更複雜。
• OIDC：利用 JSON 和 JWT，使其更加輕量和適合開發者。

現代應用程式通常偏好 OIDC 因其簡單靈活，但 SAML 在舊系統和企業使用案例中仍然盛行。

單次登錄 (SSO)#

單次登錄 (SSO) 是一種 驗證 方案，使得用戶可以憑藉一組憑證訪問多個應用程式和服務。用戶不需要單獨登入每個應用程式，只需要登入一次即可訪問所有連接的系統。

SSO 如何運作？#

SSO 倚賴一個中央的 身份提供者 (IdP) 管理用戶身份。IdP 驗證用戶並為連接的應用程式提供如驗證和授權的服務。

IdP 可以使用如 OIDC、OAuth 2.0、SAML 或其他協定來提供這些服務。一個單一的 IdP 可以支持多種協定以滿足不同應用程式的多樣需求。

基於 OIDC 的 SSO 範例#

讓我們探討一個基於 OIDC 的 SSO 範例：

在這個流程中，用戶只需登入 IdP 一次，就可在多個應用程式 (AppA 和 AppB) 上進行驗證。

企業 SSO#

雖然 SSO 是一個廣泛的概念，但你可能也會遇到 企業 SSO 這個術語，它指的是特定旨在企業環境中應用的 SSO (通常適用於員工和合作夥伴)。

當客戶要求為你的應用程式提供 SSO 時，重要的是要明確他們的需求和使用的協定。大多數情況下，這意味著對於特定的電子郵件域，他們希望你的應用程式能重定向用戶到他們的 IdP (實現企業 SSO) 進行驗證。

添加企業 SSO 提供者示例#

以下是將企業 SSO 提供者 (Banana) 與你的應用程式 (MyApp) 集成的一個簡化示例：

JWT#

JSON Web Token (JWT) 是一個由 RFC 7519 定義的開放標準，允許雙方之間的安全通訊。它是 OIDC 中 ID 令牌的標準格式，並廣泛用於 OAuth 2.0 的訪問令牌。

這裡是 JWT 的主要特點：

• 緊湊：JWT 是編碼成緊湊格式的 JSON 對象，使其易於傳輸和存儲。
• 自包含：JWT 包含關於用戶和令牌本身的所有必要資訊。
• 可驗證和可加密：JWT 可被簽名和加密以確保數據完整性和機密性。

一個典型的 JWT 看起來像這樣：

這個 JWT 由三個部分組成，用點分隔：

• Header：包含令牌的元數據，如令牌類型和簽名算法。
• Payload：包含關於身份和令牌本身的資訊。
• Signature：驗證令牌的完整性。

Header 和 Payload 都是 base64 編碼的 JSON 對象。上面的 JWT 可以這樣解碼：

使用 JWT，客戶端可以解碼令牌並提取用戶的資訊，而無需向身份提供者提出額外請求。如需了解有關 JWT 的更多資訊，請訪問 JSON Web Token (JWT)。

回顧#

我們在這篇文章中討論了很多內容。讓我們用一個例子來總結關鍵點：

假設你有一個網頁應用程式，AppA，該應用程式需要一個 身份和存取管理 (IAM) 解決方案。你選擇 Logto，一個使用 OpenID Connect (OIDC) 的身份提供者，用於驗證。由於 OIDC 是基於 OAuth 2.0 建立的，Logto 也支持你的應用程式的授權。

為了減少用戶的摩擦，你在 Logto 中啟用了「使用 Google 登入」。這利用了 OAuth 2.0 來在 Logto 和 Google 之間交換授權資料和用戶資訊。

用戶通過 Logto 登入 AppA 後，AppA 接收一個 ID 令牌，這是一個 JSON Web Token (JWT)，包含該用戶的資訊。

隨著業務的增長，你推出了一個新應用程式 AppB，它也需要用戶驗證。由於 Logto 已經設置好，你可以重用相同的驗證流程給 AppB。你的用戶現在可以憑一組憑證登入 AppA 和 AppB，這種功能被稱為 單次登錄 (SSO)。

後來，一個商業伙伴要求你連接他們的企業 SSO 系統，這個系統使用 安全聲明標記語言 (SAML)。你發現 Logto 支持 SAML 連接，因此你設置了一個 Logto 和合作夥伴 SSO 系統之間的連接。現在，合作夥伴的組織的用戶也可以使用他們現有的憑證登入 AppA 和 AppB。

---

希望這篇文章能幫助你明確這些概念。如需更深入的解釋和例子，請查看 Auth Wiki。如果你正在為你的應用程式尋找 IAM 解決方案，考慮使用像 Logto 這樣的管理服務來節省時間和精力。