[身份和訪問管理（IAM）](https://auth.wiki/iam)的領域在最近幾年變得更為複雜。像[OAuth](https://auth.wiki/oauth)、[OpenID Connect (OIDC)](https://auth.wiki/openid-connect)、[SAML](https://auth.wiki/saml)、[SSO](https://auth.wiki/single-sign-on) 和 [JWT](https://auth.wiki/jwt)這些花俏的術語經常被使用，但它們究竟是什麼意思？它們如何協作？讓我們探索這些概念和框架，以使它們更易於理解和實用。每個協議和框架都可以深入探索。本篇文章旨在提供基礎的理解。關於每個主題的詳細見解，請訪問[Auth Wiki](https://auth.wiki)。 ## 什麼是 IAM？身份和訪問管理（IAM）是一個廣泛的概念，涉及管理數字 **身份** 和實施 **訪問控制**。之前提到的框架和協議都屬於 IAM，每一個都針對這一領域的具體挑戰。本質上，IAM 涉及： - **身份**：使用者、服務或設備的數字表示。身份通常包括如姓名、電子郵件、角色等描述實體的屬性。 - **訪問**：與資源互動、執行操作或使用服務的能力。訪問定義了可以在哪些資源上執行什麼操作。 ```mermaid graph LR subgraph User Name Email Role end API User -->|GET| API ``` 在上圖中，一個使用者（身份）希望對一個 API（資源）執行 `GET` 請求。使用者的屬性 - 姓名、電子郵件和角色 - 描述了身份。 ### 驗證與授權驗證和授權經常在 IAM 的討論中一起出現。讓我們澄清它們的定義： - **驗證**：驗證身份所有權的過程。它回答問題，「你擁有哪個身份？」 - **授權**：決定經過驗證的身份可以在資源上執行哪些操作的過程。它回答問題，「你可以做什麼？」授權是訪問控制的一部分。訪問控制是一個更廣泛的概念，包括授權和其它限制。更多詳情見[訪問控制](https://auth.wiki/access-control)。在前面的例子中： - 在使用者（身份）可以執行任何操作之前，他們必須完成 **驗證** 過程。 - 驗證後，系統需要確定使用者是否可以對 API（資源）執行 `GET` 請求（操作），即完成 **授權** 過程。 --- 擁有這些基礎知識後，讓我們解開其他縮寫和協議的迷團。 ## OAuth [OAuth 2.0](https://auth.wiki/oauth-2.0)，通常簡稱為 OAuth，是一種 **授權** 框架，允許應用程序訪問另一個應用程序上的受保護資源（通常代表使用者）。例如，想象你有一個名為 *MyApp* 的網頁應用程序，想要訪問使用者的 Google Drive。與其要求使用者共享他們的 Google Drive 憑據，*MyApp* 可以使用 OAuth 2.0 向 Google 請求權限（**授權**）以訪問使用者的 Drive。這裡是一個簡化的圖表，說明 OAuth 流程： ```mermaid sequenceDiagram autonumber actor User participant MyApp participant Google User->>MyApp: 打開 MyApp 並
點擊 "連接 Google Drive" MyApp->>Google: 重定向到 Google
附帶授權請求 Google->>User: 提示 Google 登錄 User->>Google: 登錄 Google->>User: 請求訪問 Google Drive 的權限 User->>Google: 授權給 MyApp Google->>MyApp: 重定向到 MyApp
附帶訪問令牌 MyApp->>Google: 使用訪問令牌
訪問 Google Drive ``` 在此流程中： - *MyApp* 是客戶端（身份），請求訪問 Google Drive（資源）。 - 使用者（資源擁有者）在第 6 步授權 *MyApp*，完成 **授權** 過程。 OAuth 2.0 沒有定義使用者如何向 Google 驗證自己（第 3 和 4 步）。這方面由 Google 實施。 OAuth 2.0 的一個關鍵元素是 **訪問令牌**，客戶端使用它來證明使用者對資源的授權。如需深入了解，請參閱 [訪問令牌](https://auth.wiki/access-token)。 ## OpenID Connect (OIDC) [OpenID Connect (OIDC)](https://auth.wiki/openid-connect) 是在 OAuth 2.0 之上構建的 **驗證** 層。它增加了專為驗證設計的功能，比如 [ID 令牌](https://auth.wiki/id-token) 和 [UserInfo 端點](https://auth.wiki/userinfo-endpoint)，使其適用於驗證和授權。如果我們重新審視 OAuth 流程，加入 OIDC 引入了一個 **ID 令牌**。此令牌包含經過驗證的使用者信息，使 MyApp 能夠驗證使用者的身份。 ### 示例場景：「使用 Google 登錄」讓我們更換例子。如果 MyApp 想讓使用者使用他們的 Google 帳戶登錄，目標轉向驗證而不是資源訪問。在這種情況下，OIDC 更合適。這裡是 OIDC 流程的樣子： ```mermaid sequenceDiagram autonumber actor User participant MyApp participant Google User->>MyApp: 點擊 "使用 Google 登錄" MyApp->>Google: 重定向附帶驗證請求 Google->>User: 提示 Google 登錄 User->>Google: 登錄 Google->>User: 請求共享使用者信息的權限 User->>Google: 授權 Google->>MyApp: 重定向到 MyApp
附帶 ID 和訪問令牌 MyApp->>MyApp: 驗證並從 ID 令牌中提取使用者信息 ``` **關鍵區別**：除了訪問令牌，OIDC 提供一個 **ID 令牌**，允許 MyApp 驗證使用者，而無需其他請求。 OIDC 與 OAuth 2.0 共享 [授權](https://auth.wiki/oauth-2.0-grant) 定義，確保兩個框架之間的兼容性和一致性。 ## SAML [安全斷言標記語言 (SAML)](https://auth.wiki/saml) 是一種基於 XML 的框架，用於在各方之間交換 **驗證** 和 **授權** 數據。SAML 在 2000 年代初推出，已被企業環境廣泛採用。 ### SAML 與 OIDC 如何比較？ SAML 和 OIDC 在功能上類似，但在實現細節上有所不同： - **SAML**：使用基於 XML 的斷言，通常被認為更複雜。 - **OIDC**：利用 JSON 和 JWT，使其輕便且對開發者更友好。現代應用通常偏愛 OIDC 因為其簡單性和靈活性，但 SAML 在遺留系統和企業使用案例中仍然普遍存在。 ## 單一登入 (SSO) [單一登入 (SSO)](https://auth.wiki/sso) 是一種 **驗證** 方案，允許使用者使用一組憑據訪問多個應用和服務。與其逐個登錄每個應用，使用者一次登入即可獲得所有連接系統的訪問權限。 ### SSO 如何工作？ SSO 依賴於中央 [身份提供者 (IdP)](https://auth.wiki/identity-provider) 來管理用戶身份。IdP 驗證用戶並為連接的應用提供如驗證和授權的服務。 ```mermaid graph LR User --> AppA User --> AppB AppA <--> IdP[身份提供者] AppB <--> IdP User -->|SSO| IdP ``` IdP 可以使用 OIDC、OAuth 2.0、SAML 或其他協議來提供這些服務。一個 IdP 可以支持多個協議，以滿足不同應用的多樣需求。 #### OIDC 驅動的 SSO 示例讓我們探討一個基於 OIDC 的 SSO 的例子： ```mermaid sequenceDiagram actor User participant AppA participant AppB participant IdP User->>AppA: 訪問應用 A AppA->>IdP: 重定向到 IdP IdP->>User: 提示輸入憑據 User->>IdP: 提供憑據 IdP->>AppA: 發送 ID 令牌 AppA->>User: 授予訪問權限 User->>AppB: 訪問應用 B AppB->>IdP: 重定向到 IdP IdP->>IdP: 使用者已被驗證 IdP->>AppB: 發送 ID 令牌 AppB->>User: 授予訪問權限 ``` 在這個流程中，使用者登錄一次到 IdP，並跨多個應用（AppA 和 AppB）被驗證。 ### 企業 SSO 雖然 SSO 是一個廣泛的概念，你可能還會遇到 [企業 SSO](https://auth.wiki/enterprise-sso) 這一術語，它是專為企業環境設計的一種特定 SSO（通常針對員工和合作夥伴）。當客戶要求你的應用程序進行 SSO 時，重要的是要明確他們的需求及其所使用的協議。在大多數情況下，這意味著對於特定的電子郵件域，他們希望你的應用程序將使用者重定向到他們的 IdP（實施企業 SSO）進行身份驗證。 #### 示例：添加一個企業 SSO 供應商這是一個簡化的範例，說明如何將企業 SSO 供應商（Banana）與你的應用程式（MyApp）集成： ```mermaid sequenceDiagram actor User participant MyApp participant IdP as MyApp IdP participant Banana as Banana IdP User->>MyApp: 點擊 "登入" MyApp->>IdP: 重定向到 IdP IdP->>User: 提示輸入憑據 User->>IdP: 提供 Banana 電郵 IdP->>Banana: 重定向到 Banana IdP Banana->>User: 提示輸入憑據 User->>Banana: 提供憑據 Banana->>IdP: 發送回應 IdP->>MyApp: 發送回應 MyApp->>User: 授予訪問 MyApp 的權限並顯示使用者數據 ``` 重定向到 IdP 是 SSO 流程中的常見模式。這種做法使 IdP 可以維護一個用戶會話的中央點，同時為多個應用程序提供身份驗證和授權服務。 ## JWT [JSON 網絡令牌 (JWT)](https://auth.wiki/jwt) 是一個在 RFC 7519 中定義的開放標準，允許在兩方之間安全地通信。它是 OIDC 中身份令牌的標準格式，並廣泛用於 OAuth 2.0 訪問令牌。以下是 JWT 的主要特點： - **緊湊**：JWT 是 JSON 對象，編碼為緊湊格式，使其易於傳輸和存儲。 - **自包含**：JWT 包含用戶和令牌本身的所有必要信息。 - **可驗證和可加密**：JWT 可以被簽名和加密，以確保數據完整性和機密性。一個典型的 JWT 如下所示： ``` eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJmb28iLCJuYW1lIjoiSm9obiBEb2UifQ.XM-XSs2Lmp76IcTQ7tVdFcZzN4W_WcoKMNANp925Q9g ``` 這個 JWT 包含三個由點分隔的部分： ``` {{header}}.{{payload}}.{{signature}} ``` - **Header**：包含令牌的元數據，如令牌類型和簽名算法。 - **Payload**：包含關於身份和令牌本身的信息。 - **Signature**：驗證令牌的完整性。 Header 和 Payload 都是 base64 編碼的 JSON 對象。上面的 JWT 可以解碼如下： ```jsonc // Header { "alg": "HS256", "typ": "JWT" } // Payload { "sub": "foo", "name": "John Doe" } ``` 使用 JWT，客戶端無需進行其他請求即可解碼令牌並提取用戶信息。如需了解有關 JWT 的更多信息，請訪問 [JSON Web Token (JWT)](https://auth.wiki/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](https://auth.wiki)。如果你正在尋找一個適合你應用程序的 IAM 解決方案，考慮使用像 [Logto](https://logto.io) 這樣的託管服務，以節省時間和精力。