認證管理員中的 OAuth 2.0 連線 - 處理詳細資料和流程

適用於：所有 API 管理 層

本文提供在 Azure APIM 中使用認證管理員管理 OAuth 2.0 連線的處理流程詳細資料。 處理流程分為兩個部分：管理和執行階段。

如需 APIM 中認證管理員的背景資訊，請參閱關於 APIM 中的認證管理員和 API 認證。

管理連線

認證管理員中連線的管理部分會負責設定 OAuth 2.0 權杖的認證提供者、啟用提供者的同意流程，以及設定認證提供者的一或多個連線以存取認證。

下圖摘要說明的處理流程可在 APIM 中建立使用授權碼授與類型的連線。

步驟	描述:
1	用戶端會傳送要求以建立認證提供者
2	系統會建立認證提供者，並傳回回應
3	用戶端會傳送要求以建立連線
4	系統會建立連線，並傳回回應，其中包含連線未「連接」的資訊
5	用戶端會傳送要求來擷取登入 URL，以在認證提供者上啟動 OAuth 2.0 同意。 要求包含最後一個步驟中要使用的重新導向後 URL
6	回應會以應該用來啟動同意流程的登入 URL 傳回。
7	用戶端使用在前一步驟提供的登入 URL 來開啟瀏覽器。 瀏覽器會重新導向至認證提供者 OAuth 2.0 同意流程
8	核准同意後，瀏覽器會以授權碼重新導向至認證提供者上設定的重新導向 URL
9	APIM 使用授權碼來擷取存取和重新整理權杖
10	APIM 會接收權杖並將其加密
11	APIM 會從步驟 5 重新導向至已提供的 URL

認證提供者

設定認證提供者時，您可以選擇不同的 OAuth 提供者和授與類型 (授權碼或用戶端認證)。 每個提供者都需要特定的組態。 要牢記的重要事項：

• 認證提供者組態僅能有一個授與類型。
• 一個認證提供者組態可以有多個連線。

注意

有了通用 OAuth 2.0 提供者後，即可使用支援 OAuth 2.0 流程標準的其他識別提供者。

設定認證提供者時，認證管理員會在幕後建立 [認證存放區]，用來快取提供者的 OAuth 2.0 存取權杖和重新整理權杖。

連線到認證提供者

若要存取和使用提供者的權杖，用戶端應用程式需要連線到認證提供者。 [存取原則] 可根據 Microsoft Entra ID 身分識別允許指定的連線。 您可以為提供者設定多個連線。

設定連線的程序會根據設定的授與而有所不同，只適用於特定認證提供者組態。 例如，若您想要將 Microsoft Entra ID 設定為使用這兩種授與類型，則需要兩個認證提供者組態。 下表簡要說明這兩種授與類型。

授與類型	描述
授權碼	繫結至使用者內容，這表示使用者必須同意連線。 只要重新整理權杖有效，APIM 即可擷取新的存取權和重新整理權杖。 若重新整理權杖無效，使用者必須重新授權。 所有認證提供者都支援授權碼。 深入了解
用戶端認證	不會繫結至使用者，而且通常用於應用程式對應用程式案例。 用戶端認證授與類型不需要經過同意，且連線不會變成無效。 深入了解

同意

對於根據授權碼授與類型的連線，您必須向提供者進行驗證，並同意授權。 在認證提供者成功登入並授權之後，提供者會傳回有效的存取權杖和重新整理權杖，這些權杖由 APIM 加密並儲存。

存取原則

您可以為每個連線設定一或多個 [存取原則]。 存取原則可決定哪些 Microsoft Entra ID 身分識別能夠在執行階段存取認證。 這些連線目前支援使用服務主體、APIM 執行個體的身分識別、使用者和群組進行存取。

身分識別	描述	優點	考量
服務主體	當組織使用 Microsoft Entra ID 時，其權杖可用來驗證特定 Azure 資源並授與其存取權的身分識別。 透過使用服務主體，組織可避免在需要存取資源時建立虛構的使用者來管理驗證。 服務主體是代表已註冊 Microsoft Entra 應用程式的 Microsoft Entra 身分識別。	允許對連線和使用者委派案例進行更嚴格的範圍存取。 未繫結至特定的 APIM 執行個體。 依賴 Microsoft Entra ID 來強制執行權限。	取得授權內容需要 Microsoft Entra ID 權杖。
受控識別 <Your API Management instance name>	此選項對應於繫結至 APIM 執行個體的受控識別。	根據預設，系統會針對對應的 APIM 執行個體，將存取權提供給系統指派的受控識別。	身分識別會繫結至 APIM 執行個體。 擁有 APIM 執行個體參與者存取權的任何人都可以存取任何授與受控識別權限的連線。
使用者或群組	Microsoft Entra ID 租用戶中的使用者或群組。	可讓您限制特定使用者或使用者群組的存取權。	要求使用者擁有 Microsoft Entra ID 帳戶。

連線的執行階段

執行階段部分要求使用 get-authorization-context 原則設定後端 OAuth 2.0 API。 在執行階段，原則會從 APIM 為提供者設定的認證存放區中擷取並儲存存取權杖和重新整理權杖。 在呼叫進入 APIM 並執行 get-authorization-context 原則時，系統會先驗證現有授權權杖是否有效。 如果授權權杖已過期，APIM 會使用 OAuth 2.0 流程，從認證提供者重新整理預存權杖。 然後使用存取權杖來授與後端服務的存取權。

在原則執行期間，也會使用存取原則來驗證權杖的存取權。

下圖顯示根據使用授權碼授與類型的連線，以擷取並儲存授權權杖和重新整理權杖的範例處理流程。 擷取權杖後，系統會呼叫後端 API。

步驟	描述:
1	用戶端會將要求傳送至 APIM 執行個體
2	get-authorization-context 原則會檢查存取權杖是否對目前的連線有效
3	若存取權杖已過期，但重新整理權杖有效，APIM 會嘗試從已設定的認證提供者擷取新的存取權杖和重新整理權杖
4	認證提供者會同時傳回存取權杖和重新整理權杖，這些權杖會加密並儲存至 APIM
5	擷取權杖後，即會使用 set-header 原則作為授權標頭，將存取權杖連結至對後端 API 的輸出要求
6	回應會傳回至 APIM
7	回應會傳回至用戶端

相關內容

• 認證管理員概觀
• 為認證管理員設定認證提供者
• 為 Microsoft Graph API 或 GitHub API 設定和使用連線
• 為提供者設定多個授權連線
• 為使用者委派存取設定連線