繁體中文(香港)
  • iam
  • oauth
  • openid-connect
  • saml
  • sso
  • jwt

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

身份和訪問管理(IAM)的世界可能會讓人感到不知所措和困惑。但別擔心 - 這篇文章會幫你拆解它們的基本概念,幫助你看到更大的圖景,並有信心地在這個複雜的領域中導航。

Gao
Gao
Founder

身份和訪問管理(IAM)的領域在最近幾年變得更為複雜。像OAuthOpenID Connect (OIDC)SAMLSSOJWT這些花俏的術語經常被使用,但它們究竟是什麼意思?它們如何協作?讓我們探索這些概念和框架,以使它們更易於理解和實用。

什麼是 IAM?

身份和訪問管理(IAM)是一個廣泛的概念,涉及管理數字 身份 和實施 訪問控制。之前提到的框架和協議都屬於 IAM,每一個都針對這一領域的具體挑戰。

本質上,IAM 涉及:

  • 身份:使用者、服務或設備的數字表示。身份通常包括如姓名、電子郵件、角色等描述實體的屬性。
  • 訪問:與資源互動、執行操作或使用服務的能力。訪問定義了可以在哪些資源上執行什麼操作。

在上圖中,一個使用者(身份)希望對一個 API(資源)執行 GET 請求。使用者的屬性 - 姓名、電子郵件和角色 - 描述了身份。

驗證與授權

驗證和授權經常在 IAM 的討論中一起出現。讓我們澄清它們的定義:

  • 驗證:驗證身份所有權的過程。它回答問題,「你擁有哪個身份?」
  • 授權:決定經過驗證的身份可以在資源上執行哪些操作的過程。它回答問題,「你可以做什麼?」

在前面的例子中:

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

擁有這些基礎知識後,讓我們解開其他縮寫和協議的迷團。

OAuth

OAuth 2.0,通常簡稱為 OAuth,是一種 授權 框架,允許應用程序訪問另一個應用程序上的受保護資源(通常代表使用者)。

例如,想象你有一個名為 MyApp 的網頁應用程序,想要訪問使用者的 Google Drive。與其要求使用者共享他們的 Google Drive 憑據,MyApp 可以使用 OAuth 2.0 向 Google 請求權限(授權)以訪問使用者的 Drive。

這裡是一個簡化的圖表,說明 OAuth 流程:

在此流程中:

  • MyApp 是客戶端(身份),請求訪問 Google Drive(資源)。
  • 使用者(資源擁有者)在第 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 網絡令牌 (JWT) 是一個在 RFC 7519 中定義的開放標準,允許在兩方之間安全地通信。它是 OIDC 中身份令牌的標準格式,並廣泛用於 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 這樣的託管服務,以節省時間和精力。