什麼是 OIDC：從為什麼需要它到它如何運作

OpenID Connect (OIDC) 定義#

OpenID Connect (OIDC) 是一個構建在 OAuth 2.0 之上的身份認證協議。雖然 OAuth 2.0 只提供授權功能，但 OIDC 增加了身份驗證功能，為用戶授權和身份驗證場景提供了一個更標準化的解決方案。

簡單來說：OIDC = 授權協議 + 身份認證。

為什麼需要 OIDC？#

為了理解為什麼需要 OIDC，我們首先來探索 OAuth 2.0 的核心概念和工作流程，以及其在實際應用中的局限性。通過分析具體場景，我們將看到為什麼我們需要 OIDC 而不是僅僅依賴 OAuth 2.0。

OAuth 2.0 的關鍵概念和授權流程#

OAuth 2.0 (Open Authorization) 是一種授權協議，允許用戶在不分享其憑證（如用戶名和密碼）的情況下，將資源訪問權限授予第三方應用。它涉及四個主要角色：

• 資源擁有者：擁有資源的用戶
• 資源伺服器：存儲用戶資源的伺服器
• 客戶端：請求訪問用戶資源的第三方應用
• 授權伺服器：驗證用戶身份並發放訪問令牌的伺服器

一個典型的 OAuth 2.0 授權流程如下所示：

如圖所示，OAuth 2.0 主要處理為第三方客戶端發放訪問令牌以訪問用戶資源。

OAuth 2.0 的局限性#

OAuth 2.0 協議只專注於發放訪問令牌。資源伺服器驗證這些令牌並返回授權的資源。然而，資源伺服器並不知道用戶的身份。

這在早期的互聯網生態中並不是一個顯著問題。

然而，隨著像 Google、Facebook、Twitter 和 Github 這樣的平台發展起來，它們開始提供豐富的用戶資源，對第三方應用變得有價值。

雖然 OAuth 2.0 在授權第三方訪問用戶資源方面表現出色，但它也有其局限性。一個典型場景是：由於用戶信息也是一種資源，當第三方應用需要訪問基本的用戶信息時，不同的平台（如 Google、Facebook、Twitter）以不同的格式返回用戶信息，這對開發者來說是一個挑戰。

OIDC 就是為了解決這些挑戰而創建的。

OIDC 中的角色#

為了在 OAuth 2.0 之上啟用用戶身份驗證並解決其局限性，OIDC 引入了三個角色：

• 最終用戶 (EU)：最終用戶，對應於 OAuth 2.0 的資源擁有者
• 依賴方 (RP)：依賴方，對應於 OAuth 2.0 的客戶端
• OpenID 提供方 (OP)：身份認證服務提供者，對應於 OAuth 2.0 的授權伺服器和資源伺服器

OP 是核心角色，提供 OAuth 2.0 的授權功能，並將用戶信息作為一個單獨的資源處理。

OIDC 如何運作？#

OIDC 的身份驗證過程類似於 OAuth 2.0，但由於 OP 結合了授權伺服器和資源伺服器的角色，它返回訪問令牌和 ID 令牌。ID 令牌包含用戶身份信息，RP 可以通過驗證 ID 令牌來驗證用戶身份。

一個典型的工作流程如下：

這標準化了跨不同平台獲取用戶信息的方式，消除了第三方應用需要處理平台差異的需求。

OIDC 中的 ID 令牌（身份令牌）#

當用戶授權第三方應用時，OP 返回 OAuth 2.0 訪問令牌和 JWT 格式的 ID 令牌。這個 ID 令牌包含用戶身份信息，如用戶 ID、用戶名、電子郵件和頭像。RP 可以通過驗證 ID 令牌來確認用戶的身份。

作為 JWT，ID 令牌包含標準的聲明，包括以下必需的核心聲明：

• iss (發行者)：發行 ID 令牌的 OpenID 提供方的唯一標識符
• sub (主題)：用戶的唯一標識符
• aud (受眾)：接收 ID 令牌的客戶端應用標識符
• exp (過期時間)：ID 令牌過期的時間
• iat (簽發時間)：ID 令牌的簽發時間

有關 ID 令牌的詳細信息，請參閱：ID 令牌。

Userinfo 端點#

UserInfo 端點是一個由 OP 提供的標準化 HTTP API，用於獲取已驗證的用戶詳細信息。通過向這個端點發送帶有訪問令牌的 GET 或 POST 請求，你可以以 JSON 格式接收用戶信息。返回的數據包括標準化的字段，如唯一用戶 ID (sub)、用戶名 (name)、電子郵件和頭像。

獲取用戶信息的過程遵循與在 OAuth 2.0 中訪問受保護資源相同的模式。通常，從 userinfo 端點獲得的用戶信息比 ID 令牌中包含的更加全面，因為 ID 令牌主要用於身份驗證和基本用戶信息。

有關 Userinfo 端點的詳細信息，請參閱：Userinfo 端點。

請注意，從 userinfo 端點接收的用戶信息取決於授權過程中請求的範疇和授予的權限。

OIDC 中的範疇#

OIDC 中的範疇定義了 RP 可以訪問哪些用戶信息。OIDC 定義了標準範疇，其中 openid 範疇在 OIDC 認證流程中是必需的。

常見的標準範疇包括：

• openid：表示 OIDC 驗證請求
• profile：基本用戶信息，如名字和頭像
• email：用戶的電子郵件信息
• phone：用戶的電話號碼
• address：用戶的地址信息

不同的範疇返回不同的用戶信息。例如，請求 openid profile email 會在 ID 令牌和 Userinfo 中返回基本的用戶信息和電子郵件，而 openid profile email phone address 則包括電話號碼和地址信息。

基於 OIDC 的身份管理#

OIDC 不僅僅是一個身份驗證協議；它是用於構建靈活、可擴展的身份管理系統的強大工具。通過為 OAuth 2.0 添加身份驗證層，標準化用戶信息資源，併為擴展的身份管理功能奠定基礎，OIDC 支援各種身份管理場景：

• 單一登錄 (SSO)：OIDC 自然支持 SSO，通過擴展的用戶會話信息，實現統一的登錄狀態管理和跨應用的身份共享
• 組織結構管理：擴展的用戶組織信息可以管理複雜的組織結構，包括部門層級和用戶組關係
• 權限管理：擴展的用戶權限屬性允許對資源訪問進行細粒度控制，包括角色信息和權限策略配置

OIDC 的靈活性能夠適應不斷變化的身份管理需求。許多身份管理系統都是基於 OIDC 構建的，例如 Logto，提供了 SSO、組織管理和權限管理功能。