Azure API 管理中 API 的身份验证和授权
适用于：所有 API 管理层级
本文介绍了 API 管理中的一组丰富、灵活的功能，这些功能可帮助保护用户对托管 API 的访问。
API 管理中的 API 身份验证和授权涉及到确保客户端应用到 API 管理网关以及到后端 API 的端到端通信。 在许多客户环境中，OAuth 2.0 是首选的 API 授权协议。 API 管理支持客户端和 API 管理网关之间、网关和后端 API 之间或两者之间的 OAuth 2.0 授权。
API 管理支持其他客户端和服务端身份验证和授权机制，这些机制补充了 OAuth 2.0，或者在无法对 API 进行 OAuth 2.0 授权时非常有用。 如何从这些选项中进行选择取决于贵组织的 API 环境成熟度、安全性和合规性要求，以及贵组织缓解常见 API 威胁的方法。
重要
保护用户对 API 的访问是保护 API 管理环境的众多考虑因素之一。 有关详细信息，请参阅 API 管理的 Azure 安全基线。
注意
其他 API 管理组件具有单独机制来保护和限制用户访问：
- 为了通过 Azure 控制平面管理 API 管理实例，API 管理依赖于 Microsoft Entra ID 和 Azure 基于角色的访问控制 (RBAC)。
- API 管理开发人员门户支持多种选项，以辅助安全用户注册和登录。
身份验证和授权
以下是在访问 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 或 API 管理网关本身）。
客户端调用 API 并提供访问令牌 - 例如，在授权标头中。
资源服务器验证访问令牌。 验证是一个复杂的过程，包括检查颁发者和受众声明是否包含预期值。
然后，根据令牌验证条件授予对后端 API 资源的访问权限。
根据客户端应用和方案的类型，请求和管理令牌需要不同的授权流。 例如，在调用 Web API 的应用中通常使用授权代码流和授权类型。 详细了解 Microsoft Entra ID 中的 OAuth 流和应用程序方案。
API 管理中的 OAuth 2.0 授权方案
方案 1 - 客户端应用程序直接向后端授权
常见的授权方案是，调用应用程序直接请求访问后端 API，并在网关的授权标头中提供 OAuth 2.0 令牌。 然后，Azure API 管理充当调用方和后端 API 之间的“透明”代理，并将令牌原封不动地传递给后端。 访问令牌的范围在调用方应用程序与后端 API 之间。
下图显示了 Microsoft Entra ID 是授权提供程序的示例。 客户端应用可能是单页应用程序 (SPA)。
尽管与 HTTP 请求一起发送的访问令牌适合后端 API，但 API 管理仍然允许深度防御方法。 例如，将策略配置为验证 JWT，拒绝收到的没有令牌的请求，或者对目标后端 API 无效的令牌。 还可以将 API 管理配置为检查从令牌中提取的其他相关声明。
注意
如果以此方式使用 OAuth 2.0 保护通过 Azure API 管理公开的 API，则可以将 API 管理配置为代表 Azure 门户或开发人员门户测试控制台用户生成有效的令牌来进行测试。 需要将 OAuth 2.0 服务器添加到 API 管理实例，并在 API 中启用 OAuth 2.0 授权设置。 有关详细信息，请参阅如何通过配置 OAuth 2.0 用户授权来为开发人员门户的测试控制台授权。
示例：
提示
在使用 Microsoft Entra ID 保护 API 访问的特殊情况下，可以配置 validate-azure-ad-token 策略进行令牌验证。
方案 2 - 客户端应用授权给 API 管理
在此方案中，API 管理服务代表 API 执行操作，调用方应用程序请求访问 API 管理实例。 访问令牌的范围在调用应用程序和 API 管理网关之间。 在 API 管理中，配置策略 (validate-jwt 或 validate-azure-ad-token) 以在网关将请求传递到后端之前验证令牌。 单独的机制通常可以保护网关和后端 API 之间的连接。
在以下示例中，Microsoft Entra ID 再次是授权提供程序，相互 TLS (mTLS) 身份验证确保网关和后端之间的连接安全。
这样的原因各有不同。 例如：
后端是旧版 API，无法将其更新以支持 OAuth
首先应将 API 管理配置为验证令牌（至少应检查颁发者和受众声明）。 验证后，使用多个可用选项之一保护来自 API 管理的后续连接，例如相互 TLS (mTLS) 身份验证。 请参阅本文稍后介绍的服务端选项。
无法从调用方建立后端所需的上下文
在 API 管理成功验证从调用方接收的令牌后，它需要使用自身的上下文或从调用方应用程序派生的上下文来获取后端 API 的访问令牌。 可使用以下任一方式来实现此方案：
自定义策略（如 send-request），用于从配置的标识提供者获取对后端 API 有效的前向访问令牌。
使用 API 管理实例自身的标识 - 将令牌从 API 管理资源的系统分配或用户分配的托管标识传递给后端 API。
组织希望采用标准化授权方法
无论 API 后端上的身份验证和授权机制如何，组织都可以选择聚合到 OAuth 2.0 上，以在前端实现标准化授权方法。 随着组织后端的发展，API 管理的网关可以为 API 用户提供一致的授权配置和共同的体验。
其他保护 API 的选项
虽然首选授权，并且 OAuth 2.0 已成为为 API 启用强授权的主要方法，但 API 管理提供了其他几种机制来保护或限制客户端与网关（客户端）或网关与后端（服务端）之间的访问。 根据组织的要求，这些可以用于补充 OAuth 2.0。 或者，如果调用应用程序或后端 API 是旧版或尚不支持 OAuth 2.0，则可以独立配置它们。
客户端选项
| 机制 | 说明 | 注意事项 |
|---|---|---|
| mTLS | 验证连接客户端提供的证书，并根据 API 管理中管理的证书检查证书属性 | 证书可以存储在密钥保管库中。 |
| 限制调用方 IP | 筛选（允许/拒绝）来自特定 IP 地址或地址范围的调用。 | 用于限制对某些用户或组织的访问，或对来自上游服务的流量的访问。 |
| 订阅密钥 | 基于 API 管理订阅限制对一个或多个 API 的访问 | 我们建议除了使用订阅 (API) 密钥以外，还使用另一种身份验证或授权方法。 订阅密钥本身并不是一种强身份验证形式，但在某些情况下，使用订阅密钥可能很有用，例如，跟踪单个客户的 API 使用情况或授予对特定 API 产品的访问权限。 |
提示
为了深入防御，强烈建议在 API 管理实例的上游部署 Web 应用程序防火墙。 例如，使用 Azure 应用程序网关。
服务端选项
| 机制 | 说明 | 注意事项 |
|---|---|---|
| 托管标识身份验证 | 使用系统分配或用户分配的托管标识对后端 API 进行身份验证。 | 建议通过从 Microsoft Entra ID 获取令牌来对受保护的后端资源进行范围访问。 |
| 证书身份验证 | 使用客户端证书对后端 API 进行身份验证。 | 证书可以存储在密钥保管库中。 |
| 基本身份验证 | 使用通过授权标头传递的用户名和密码对后端 API 进行身份验证。 | 如果有更好的选择，则不建议。 |
后续步骤
- 详细了解 Microsoft 标识平台中的身份验证和授权。
- 了解如何使用 API 管理缓解 OWASP API 安全威胁。