Azure API 管理中 API 的驗證和授權 \(部分機器翻譯\)
適用於：所有 API 管理 層
本文將介紹 APIM 中一組豐富且有彈性的功能，可協助您保護使用者對受控 API 的存取。
API 管理中的 API 驗證和授權涉及保護用戶端應用程式對 API 管理閘道以及透過後端 API 的端對端通訊。 在許多客戶環境中，OAuth 2.0 是慣用的 API 授權通訊協定。 APIM 支援在用戶端與 APIM 閘道之間、閘道與後端 API 之間，或兩者獨立進行 OAuth 2.0 授權。
APIM 支援其他用戶端和服務端驗證與授權機制，這些機制可補充 OAuth 2.0，或者在無法對 API 進行 OAuth 2.0 授權時很有用。 從這些選項中選擇的方式取決於組織 API 環境的成熟度、您的安全性與合規性需求，以及組織用來減輕常見 API 威脅的方法。
重要
保護使用者對 API 的存取是保護 API 管理環境的許多考量因素之一。 如需詳細資訊，請參閱適用於 API 管理的 Azure 安全性基準 \(部分機器翻譯\)。
注意
其他 APIM 元件均具有不同的機制來保護和限制使用者存取：
- 為了透過 Azure 控制平面管理 APIM 執行個體，APIM 依賴 Microsoft Entra ID 和 Azure 角色型存取控制 (RBAC)。
- APIM 開發人員入口網站支援數個選項，有利於使用者安全註冊及登入。
驗證和授權
以下是存取 API 內容中驗證和授權的簡短說明：
驗證 - 驗證存取 API 的使用者或應用程式身分識別的程序。 驗證可透過使用者名稱和密碼、憑證或藉由單一登入 (SSO) 或其他方法等認證來完成。
授權 - 判斷使用者或應用程式是否具有存取特定 API 權限的程序，通常是透過 OAuth 2.0 之類的權杖型通訊協定。
注意
為了補充驗證和授權，也應該使用 TLS 保障 API 的存取權，以保護用於驗證或授權的認證或權杖安全。
OAuth 2.0 概念
OAuth 2.0 (英文) 是一種標準授權架構，廣泛用來保護對 Web API 等資源的存取。 OAuth 2.0 會限制用戶端應用程式可代表使用者對資源執行的動作，且永遠不需要共用使用者的認證。 雖然 OAuth 2.0 不是驗證通訊協定，但通常會與 OpenID Connect (OIDC) 搭配使用，其透過提供使用者驗證和 SSO 功能來擴充 OAuth 2.0。
OAuth 流程
當用戶端應用程式透過使用 TLS 和 OAuth 2.0 保護的要求來呼叫 API 時，會發生什麼事？ 以下為經過簡化的範例流程：
用戶端 (呼叫的應用程式，或持有人) 使用「識別提供者」的認證進行驗證。
用戶端會從識別提供者的「授權伺服器」取得限時的「存取權杖」 (JSON Web 權杖或 JWT)。
識別提供者 (例如 Microsoft Entra ID) 是權杖的「簽發者」，而權杖包含「對象宣告」，可授權存取「資源伺服器」 (例如，後端 API 或 APIM 閘道本身)。
用戶端會呼叫 API 並提供存取權杖，例如，在授權標頭中。
資源伺服器」會驗證存取權杖。 驗證是一道複雜的程序，包括檢查「簽發者」和「對象」宣告是否包含預期的值。
隨後，系統會根據權杖驗證準則來授與後端 API 資源的存取權。
視用戶端應用程式的類型和案例而定，要求和管理權杖需要不同的「授權流程」。 例如，授權碼流程和授與類型通常用於呼叫 Web API 的應用程式。 深入了解 Microsoft Entra ID 中的 OAuth 流程和應用程式案例。
APIM 中的 OAuth 2.0 授權案例
案例 1：用戶端應用程式直接授權給後端
有個常見的授權案例是呼叫應用程式要求直接存取後端 API，並在授權標頭中將 OAuth 2.0 權杖提供給閘道。 然後，Azure APIM 會作為呼叫者與後端 API 之間的「透明」Proxy，並將權杖原封不動地傳遞到後端。 存取權杖的範圍介於呼叫應用程式和後端 API 之間。
下圖顯示 Microsoft Entra ID 為授權提供者的範例。 用戶端應用程式可能是單頁應用程式 (SPA)。
儘管連同 HTTP 要求一起傳送的存取權杖適用於後端 API，APIM 仍允許深層防禦方法。 例如，設定原則來驗證 JWT，拒絕未取得權杖的要求，或對預定後端 API 無效的權杖。 您也可以設定 APIM 來檢查從權杖擷取的其他相關宣告。
注意
如果您以此方式使用 OAuth 2.0 保護透過 Azure APIM 公開的 API，則可設定 APIM，代表 Azure 入口網站或開發人員入口網站測試主控台使用者產生有效權杖以供測試之用。 您必須將 OAuth 2.0 伺服器新增至 APIM 執行個體，並在 API 中啟用 OAuth 2.0 授權設定。 如需詳細資訊，請參閱如何透過設定 OAuth 2.0 使用者授權來授權開發人員入口網站的測試主控台。
範例：
提示
在使用 Microsoft Entra ID 保護 API 存取的特殊案例中，您可以設定 validate-azure-ad-token 原則來進行權杖驗證。
案例 2：用戶端應用程式授權給 APIM
在此案例中，APIM 服務會代表 API 運作，而呼叫應用程式會要求存取 APIM 執行個體。 存取權杖的範圍介於呼叫應用程式和 APIM 閘道之間。 在 APIM 中，設定原則 (validate-jwt 或 validate-azure-ad-token)，在閘道將要求傳遞到後端之前驗證權杖。 個別的機制通常會保護閘道與後端 API 之間的連線。
在下列範例中，Microsoft Entra ID 再次作為授權提供者，而相互 TLS (mTLS) 驗證會保護閘道與後端之間的連線。
這樣做有很多不同的理由。 例如：
後端是舊版 API，無法更新以支援 OAuth
APIM 首先應設為驗證權杖 (至少檢查簽發者和對象宣告)。 驗證之後，使用數個可用選項之一，保護來自 APIM 的後續連線，例如，相互 TLS (mTLS) 驗證。 請參閱本文稍後的服務端選項。
後端所需內容無法從呼叫者建立
在 APIM 成功驗證從呼叫者收到的權杖後，接著必須使用自己的內容，或衍生自呼叫應用程式的內容，取得後端 API 的存取權杖。 您可以使用下列任一方法完成此案例：
自訂原則 (例如 send-request)，可從設定的識別提供者取得後端 API 的有效後續存取權杖。
APIM 執行個體自身的身分識別 – 將權杖從 APIM 資源的系統指派或使用者指派的受控識別傳遞至後端 API。
組織想要採用標準化授權方法
無論 API 後端上的驗證和授權機制為何，組織都可以選擇在 OAuth 2.0 上形成交集，以在前端採用標準化授權方法。 隨著組織後端的發展，APIM 的閘道可以啟用一致的授權設定和 API 取用者的常見體驗。
案例 3：APIM 授權給後端
使用受控連線 (先前稱為「授權」)，您可以使用 APIM 中的認證管理員來授權存取一或多個後端或 SaaS 服務，例如，LinkedIn、GitHub 或其他 OAuth 2.0 相容後端。 在此案例中，使用者或用戶端應用程式會向 APIM 閘道提出要求，並使用識別提供者或其他用戶端選項來控制閘道存取。 然後，透過原則設定，使用者或用戶端應用程式會將後端驗證和授權委派給 APIM。
在下列範例中，會在用戶端與閘道之間使用訂用帳戶金鑰，而 GitHub 是後端 API 的認證提供者。
透過與認證提供者的連線，APIM 會在 OAuth 2.0 流程中取得並重新整理用於 API 存取的權杖。 連線可在多個案例中簡化權杖管理，例如：
- 用戶端應用程式可能需要向多個 SaaS 後端授權，才能使用 GraphQL 解析器來解析多個欄位。
- 使用者透過 SSO 從其識別提供者對 APIM 進行驗證，但會使用通用組織帳戶來向後端 SaaS 提供者 (例如 LinkedIn) 授權。
- 用戶端應用程式 (或 Bot) 必須代表已驗證的使用者存取後端保護的線上資源 (例如，檢查電子郵件或下單)。
範例：
保護 API 的其他選項
儘管授權是慣用選項，而且 OAuth 2.0 已成為啟用 API 強式授權的主要方法，但 APIM 提供數種其他機制來保護或限制用戶端與閘道 (用戶端) 之間或閘道與後端 (服務端) 之間的存取。 根據組織的需求，這些均可用來補充 OAuth 2.0。 或者，如果呼叫應用程式或後端 API 是舊版或尚不支援 OAuth 2.0，請獨立設定它們。
用戶端選項
| 機制 | 描述 | 考量 |
|---|---|---|
| mTLS | 驗證憑證 (由連線用戶端所提供)，並針對 APIM 中管理的憑證檢查憑證屬性 | 憑證可以儲存在金鑰保存庫中。 |
| 限制呼叫端 IP | 篩選 (允許/拒絕) 來自特定 IP 位址或位址範圍的呼叫。 | 用來限制對特定使用者或組織的存取，或限制來自上游服務的流量。 |
| 訂用帳戶金鑰 | 根據 APIM 訂用帳戶限制對一或多個 API 的存取 | 我們建議在另外的驗證或授權方法之外，使用訂閱 (API) 金鑰。 訂用帳戶金鑰本身不是強式驗證形式，但在某些案例中使用訂用帳戶金鑰可能很有幫助，例如，追蹤個別客戶的 API 使用量，或授與對特定 API 產品的存取權。 |
提示
若要進行深層防禦，強烈建議您部署 APIM 執行個體的 Web 應用程式防火牆上游。 例如，使用 Azure 應用程式閘道或 Azure Front Door。
服務端選項
| 機制 | 描述 | 考量 |
|---|---|---|
| 受控識別驗證 | 使用系統指派或使用者指派的受控識別，對後端 API 進行驗證。 | 建議從 Microsoft Entra ID 取得權杖，以將範圍限定為存取受保護的後端資源。 |
| 憑證驗證 | 使用用戶端憑證來對後端 API 進行驗證。 | 憑證可以儲存在金鑰保存庫中。 |
| 基本驗證 | 使用透過授權標頭傳遞的使用者名稱和密碼，對後端 API 進行驗證。 | 如果有更好的選項可供使用，則不建議使用。 |
下一步
- 深入了解 Microsoft 身分識別平台中的驗證與授權。
- 了解如何使用 APIM 減輕 OWASP API 的安全性威脅。