繁體中文（台灣）

oidc
openid connect
oauth
authentication
authorization

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

了解 OIDC 是什麼，為什麼需要它，以及它是如何運作的。發現 OIDC 如何擴展 OAuth 2.0 進行身份驗證，了解其核心組件，包括 ID Token、範疇和 userinfo 端點。

Yijun

Developer

12/16/2024

不要在使用者認證上浪費數週時間

使用 Logto 更快地發布安全應用程式。幾分鐘內整合使用者認證，專注於您的核心產品。

立即開始

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、組織管理和權限管理功能。

OpenID Connect (OIDC) 定義#

為什麼需要 OIDC？#

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

OAuth 2.0 的局限性#

OIDC 中的角色#

OIDC 如何運作？#

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

Userinfo 端點#

OIDC 中的範疇#

基於 OIDC 的身份管理#

OpenID Connect (OIDC) 定義#

為什麼需要 OIDC？#

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

OAuth 2.0 的局限性#

OIDC 中的角色#

OIDC 如何運作？#

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

Userinfo 端點#

OIDC 中的範疇#

基於 OIDC 的身份管理#

OpenID Connect (OIDC) 定義

為什麼需要 OIDC？

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

OAuth 2.0 的局限性

OIDC 中的角色

OIDC 如何運作？

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

Userinfo 端點

OIDC 中的範疇

基於 OIDC 的身份管理

OpenID Connect (OIDC) 定義

為什麼需要 OIDC？

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

OAuth 2.0 的局限性

OIDC 中的角色

OIDC 如何運作？

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

Userinfo 端點

OIDC 中的範疇

基於 OIDC 的身份管理