適用於：所有 API 管理層
本文提供在 Azure API 管理中使用認證管理員管理 OAuth 2.0 連線的程式流程的詳細資料。 流程分為兩部分：管理和執行階段。
如需 API 管理 中認證管理員的背景，請參閱 關於認證管理員和 API 管理中的 API 認證。
連線管理
認證管理員中連線的 管理 部分負責設定和設定 OAuth 2.0 權杖的 認證提供者 、啟用提供者的同意流程，以及設定一或多個與認證提供者的 連線 以存取認證。
下圖摘要說明在 API 管理 中建立使用授權碼授與類型的連線的程式流程。
| Step | Description |
|---|---|
| 1 | 用戶端會傳送要求以建立認證提供者。 |
| 2 | 建立認證提供者，並傳回回應。 |
| 3 | 用戶端會傳送建立連線的要求。 |
| 4 | 系統會建立連線，並傳回回應，其中包含連線未「連接」的資訊。 |
| 5 | 用戶端會傳送要求以擷取登入URL，以在認證提供者處啟動OAuth 2.0同意。 請求包含一個在最後步驟中要使用的重新導向 URL。 |
| 6 | 回應會傳回登入URL，該URL應該用來啟動同意流程。 |
| 7 | 用戶端會開啟瀏覽器，其中包含上一個步驟中提供的登入 URL。 瀏覽器會重新導向至認證提供者的 OAuth 2.0 同意流程。 |
| 8 | 核准同意之後，瀏覽器會使用授權碼重新導向至認證提供者所設定的重新導向 URL。 |
| 9 | APIM 使用授權代碼來擷取存取權和重新整理權杖。 |
| 10 | API 管理 會接收權杖並加密它們。 |
| 11 | API 管理 會重新導向至步驟 5 中提供的 URL。 |
認證提供者
設定認證提供者時，您可以在不同的 OAuth 提供者 和授權類型 （授權碼或用戶端認證） 之間進行選擇。 每個提供者都需要特定的配置。 需要記住的重要事項：
- 認證提供者組態只能有一個授與類型。
- 一個認證提供者組態可以有 多個連線。
備註
使用一般 OAuth 2.0 提供者時，可以使用支援 OAuth 2.0 流程 標準的其他身分識別提供者。
當您設定認證提供者時，憑證管理員會在幕後建立 憑證存放區，用來暫存提供者的 OAuth 2.0 存取權杖和重新整理權杖。
連線至認證提供者
若要存取及使用提供者的權杖，用戶端應用程式需要連線到認證提供者。 以 Microsoft Entra ID 身分識別為基礎的 存取原則 允許指定的連線。 您可以為提供者設定多個連線。
設定連線的程式會根據設定的授權而有所不同，且特定於認證提供者設定。 例如，如果您想要將 Microsoft Entra ID 設定為使用這兩種授與類型，則需要兩個認證提供者設定。 下表摘要說明兩種授權類型。
| 授與類型 | Description |
|---|---|
| 授權碼 | 繫結至使用者環境，表示使用者需要同意連線。 只要重新整理權杖有效，APIM 即可擷取新的存取權和重新整理權杖。 如果 refresh token 變得無效，使用者需要重新授權。 所有認證提供者都支援授權碼。 瞭解更多資訊 |
| 用戶端認證 | 不綁定至使用者，且通常用於應用程式間的情境。 用戶端認證授與類型不需要同意，而且連線不會變成無效。 瞭解更多資訊 |
同意
對於以授權碼授與類型為基礎的連線，您必須向提供者進行鑑別並 同意 授權。 認證提供者在成功登入和授權後，會傳回有效的存取權杖和更新權杖，這些權杖會由 API 管理進行加密並儲存。
存取原則
您可以為每個連線設定一或多個 存取原則 。 存取原則會決定哪些 Microsoft Entra ID 身分識別 能夠在執行階段存取您的認證。 目前，連線支援透過服務主體、API 管理實例的身分識別、使用者和群組進行存取。
| 身份 | Description | 優點 | 考慮事項 |
|---|---|---|---|
| 服務主體 | 在組織使用 Microsoft Entra ID 時，其語彙基元可用來驗證特定 Azure 資源並授與其存取權的身分識別。 藉由使用服務主體，組織可以避免在需要存取資源時建立虛構使用者來管理驗證。 服務主體是代表已註冊 Microsoft Entra 應用程式的 Microsoft Entra 身分識別。 | 允許對連線和使用者授權情境提供更為精確的存取範圍。 未繫結至特定 API 管理 實例。 依賴 Microsoft Entra ID 來強制執行許可權。 | 取得 授權上下文 需要 Microsoft Entra ID 存取權杖。 |
受控識別 <Your API Management instance name> |
此選項對應至繫結至 API 管理 實例的受控識別。 | 根據預設，系統會針對對應的 APIM 執行個體，將存取權提供給系統指派的受控識別。 | 身分識別會繫結至您的 API 管理 實例。 具有 API 管理 執行個體參與者存取權的任何人都可以存取任何授與受控識別許可權的連線。 |
| 使用者或群組 | Microsoft Entra ID 租戶中的使用者或群組。 | 可讓您將存取權限制為特定使用者或使用者群組。 | 要求使用者具有 Microsoft Entra ID 帳戶。 |
連線的執行階段
執行階段部分需要使用 get-authorization-context 原則來設定後端 OAuth 2.0 API。 在執行階段，原則會從 APIM 為提供者設定的認證存放區中擷取並儲存存取權杖和重新整理權杖。 當 API 管理服務接收到呼叫並執行 get-authorization-context 規則時，首先會驗證現有的存取權杖是否有效。 如果授權權杖已過期，API 管理 會使用 OAuth 2.0 流程來重新整理認證提供者的儲存權杖。 然後，存取權杖會用來授權存取後端服務。
在原則執行期間，也會使用存取原則來驗證權杖的存取權。
下圖顯示根據使用授權碼授與類型的連線，以擷取並儲存授權權杖和重新整理權杖的範例處理流程。 取得令牌之後，會呼叫後端 API。
| Step | Description |
|---|---|
| 1 | 用戶端會將要求傳送至 API 管理 實例。 |
| 2 | get-authorization-context 原則會檢查存取權杖對目前連線是否有效。 |
| 3 | 如果存取權杖已過期，但重新整理權杖有效，API 管理 會嘗試從設定的認證提供者擷取新的存取和重新整理權杖。 |
| 4 | 認證提供者會傳回存取權杖和重新整理權杖，這些權杖會加密並儲存至 API 管理。 |
| 5 | 擷取語彙基元後，存取語彙基元會使用 set-header 原則作為授權標頭，附加至後端 API 的輸出要求。 |
| 6 | 回應會傳回給 API 管理。 |
| 7 | 回應會傳回給用戶端。 |
相關內容
- 認證管理員概觀
- 為認證管理員設定認證提供者
- 為 Microsoft Graph API 或 GitHub API 設定和使用連線
- 為提供者設定多個授權連線
- 為使用者委派存取設定連線