探索 OpenID Connect 配置：關鍵欄位及其應用

在當今的數位世界中，身份驗證已成為保障網站和應用程式安全的核心組成部分。OpenID Connect (OIDC) 是一個建構於 OAuth 2.0 協議之上的身份驗證層，提供了一種標準化且簡單的方法來驗證身份。

然而，正確整合 OIDC 可能是令人生畏的，特別是對於新手來說。一個不錯的起點通常是 OIDC 配置文件，通常位於 {authServerUrl}/.well-known/openid-configuration 的 URL 中，該文件包含實施 OIDC 服務所需的所有詳細資訊。

本指南旨在釐清這些配置中的關鍵欄位，幫助開發者理解其重要性及實際應用，以便在他們的專案中更好地整合 OIDC。

分析 OIDC 配置欄位#

OIDC 配置是一個類似於以下的 JSON 文件：

接下來，我們將深入探討一些關鍵欄位。

authorization_endpoint#

在整合 OIDC 服務時，第一步通常涉及在應用程式中處理用戶登錄請求。此過程包括將用戶重定向到授權伺服器的 authorization_endpoint。該端點是授權請求的發送地點，引導用戶登錄頁面以完成身份驗證。

在向 authorization_endpoint 發送請求時，必須為每次授權配置其他查詢參數：

• response_type: 指定返回的授權類型。這通常包括 "code"（用於授權碼流程）、"token"（用於隱式流程）和 "id_token token" 或 "code id_token"（用於混合流程），這些可以在 OIDC 配置的 response_types_supported 欄位中找到。
• client_id: 當應用註冊時授權伺服器分配給應用程式的一個唯一標識符。授權伺服器使用此 ID 識別發出請求的客戶端應用程式。
• scope: 定義請求的存取範圍，指定可存取的資源或用戶資訊。常見的範圍包括 "openid"（必選）、"profile" 和 "email" 等。可以在 OIDC 配置的 scopes_supported 欄位中找到支持的範圍；不同的範圍應以空格分隔。
• redirect_uri: 登錄或授權後，授權伺服器將用戶重定向回應用程式提供的 URI。此 URI 必須嚴格匹配應用註冊時提供的 URI。
• state: 一個隨機生成的字串，用於保護客戶端免受跨站請求偽造攻擊。在授權請求和回呼之間必須保持狀態的一致性，以確保安全性。

這些參數允許開發者精確控制 OIDC 授權請求的行為，確保它們安全且符合應用需求。

完成前往 authorization_endpoint 的請求和身份驗證後，用戶將被重定向到指定的 redirect_uri，其中將包含一個非常重要的查詢參數 —— code。這個授權碼由授權伺服器提供，是用戶在授權伺服器上完成身份驗證和授權後，應用獲得存取資訊的結果。

token_endpoint#

token_endpoint 是授權伺服器用來將上述授權碼交換為存取和刷新權杖的伺服器端點。在 OAuth 2.0 授權碼流程中，這一步至關重要，因為它涉及將獲得的授權碼轉換為實際的存取權杖，應用可以用該權杖來存取用戶的受保護資源。

以下是如何將授權碼交換為存取權杖的實現（注意此範例使用 client_secret_post 驗證方法。對於其他支持的驗證方法，請參考稍後對

欄位的分析）：

在這段代碼中，我們首先使用 POST 方法向 token_endpoint 發送請求。內容類型設置為 application/x-www-form-urlencoded，這是大多數授權伺服器的要求。請求正文包括以下參數：

• code: 從授權伺服器獲得的授權碼，這是用戶在完成授權後通過 redirectUri 返回的。
• redirect_uri: 用於獲得授權碼時使用的相同 URI，用於驗證請求的合法性。
• client_id: 應用的客戶端標識符，用於識別發出請求的應用。
• client_secret: 應用的客戶端密鑰，用於驗證應用的身份。
• grant_type: 指定授權類型，此處使用 "authorization_code"，表示存取權杖是通過授權碼獲得的。

此函數是以異步方式執行的，並返回包含存取權杖的 JSON 對象，應用可以使用該權杖請求用戶資料或執行其他操作。

userinfo_endpoint#

userinfo_endpoint 是授權伺服器用來獲得已驗證用戶詳細資訊的伺服器端點。用戶成功授權並通過 token_endpoint 獲取存取權杖後，應用可以請求該端點以存取用戶的個人資料信息，如用戶名和電子郵件地址。具體獲得的信息取決於用戶在身份驗證請求中指定的 scope。

在此函數中，我們首先使用 GET 方法請求 userinfo_endpoint，在請求頭中包括由 token_type 和 accessToken 組成的 Authorization 欄位。這是符合 OAuth 2.0 規範的標準操作，確保安全地檢索用戶信息。此外，通過存取權杖訪問的用戶信息範圍完全取決於用戶在授權發起期間採用的 scope 參數值。例如，如果使用了 email 範圍，則響應應包含用戶的電子郵件地址。

issuer & jwks_uri#

issuer 可辨識授權伺服器的 URL，而 jwks_uri 提供用於檢驗 JWT 簽名的 JSON Web Key Set (JWKS) 的 URI。檢驗 JWT 的 issuer 和簽名是確保權杖安全的基本步驟，但在真實的情況下，檢驗過程通常還包括檢查權杖的有效期、受眾、授權範圍及其他重要欄位。

以下代碼主要展示如何使用 issuer 和 jwks_uri 來驗證 JWT：

scopes_supported & claims_supported#

claims_supported 和 scopes_supported 欄位聲明授權伺服器支持的用戶屬性（claims）和訪問範圍（scopes）。它們幫助客戶端了解授權伺服器支持哪些用戶屬性和訪問範圍，使客戶端能夠有效地構建授權請求並解析響應。

在構建授權請求時，客戶端可以根據應用需求指定必要的 scope。scope 定義客戶端請求存取的資源和操作，例如 openid、email、profile 等。

值得注意的是，每次授權請求中可存取的具體 claims 會基於身份驗證請求開始時指定的 scope 值而有所不同。例如，email 範圍允許訪問用戶的電子郵件地址，而 phone 範圍提供用戶的電話號碼。因此，客戶端應根據應用需求在構建授權請求時謹慎選擇相關的 scope，確保能夠檢索到必要的用戶屬性：

token_endpoint_auth_methods_supported

#

欄位指示權杖端點支持的驗證方法。這些方法由客戶端用來在授權碼交換為存取權杖時驗證授權伺服器。

在使用權杖端點進行驗證時，常見的驗證方法包括 client_secret_post、client_secret_basic 和 client_secret_jwt。

• client_secret_post: 客戶端使用其客戶端標識符和客戶端密鑰構建一個表單編碼的正文，作為請求正文的一部分發送。在上面的 token_endpoint 部分中，我們已經看到此方法的示例。

• client_secret_basic: 客戶端使用其客戶端標識符和客戶端密鑰構建一個基本驗證標頭，並將其添加到請求標頭中。

• client_secret_jwt: 客戶端使用 JWT (JSON Web Token) 作為客戶端斷言進行驗證。此 JWT 包含客戶端標識符和一些附加元數據，並使用客戶端密鑰進行簽名。授權伺服器在收到請求後，通過驗證 JWT 的簽名來檢驗客戶端的身份。

在實際應用中，客戶端需要根據授權伺服器支持的方法選擇適當的驗證方法，並確保驗證資訊正確地添加到請求中，以安全地將授權碼交換為存取權杖。

總結#

我們現在已經探討了 OIDC 配置中的關鍵欄位，著重於其目的和應用。理解這些詳細資訊將增強你對 OpenID Connect 的掌握，使你能夠更有效地在專案中整合和利用它。掌握這些知識後，你將能夠更好地利用 OIDC 的全部潛力，為用戶提供更安全和高效的身份驗證解決方案。

Logto 作為基於 OIDC 的身份驗證服務，提供了一套全面的多種語言的 SDK 以及大量的整合教程，使你能夠在短短幾分鐘內將 OAuth / OIDC 登錄無縫整合到應用程式中。如果你在尋找可靠且易於使用的 OIDC 服務，今天就試試 Logto 吧！