在一篇文章中理解 IAM、OAuth、OpenID Connect、SAML、SSO 和 JWT
身份和訪問管理(IAM)的世界可能會讓人感到不知所措和困惑。但別擔心 - 這篇文章會幫你拆解它們的基本概念,幫助你看到更大的圖景,並有信心地在這個複雜的領域中導航。
身份和訪問管理(IAM)的領域在最近幾年變得更為複雜。像OAuth、OpenID Connect (OIDC)、SAML、SSO 和 JWT這些花俏的術語經常被使用,但它們究竟是什麼意思?它們如何協作?讓我們探索這些概念和框架,以使它們更易於理解和實用。
什麼是 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 這樣的託管服務,以節省時間和精力。