从使用移动设备订购您爱喝的咖啡，到通过体育赛事应用查阅实时比分，乃至于通过您现在使用的设备阅读这篇博文，在我们当今体验到的每一次数字化互动背后，都有着 API 的支持。由 API 提供支持的互动面不断扩大，潜在的攻击面也在随之扩大。有关 API 安全性洞见和趋势的 2022 年 Google Cloud 报告中提到，有超过 50% 的组织在 2021 年至少遭遇过一次 API 相关安全性威胁，印证了 API 已然成为恶意人员趋之若鹜的目标之一。要保护 API，您需要制定谨慎的策略和多层式方法。但任何优秀 API 策略的基石都是对尝试访问 API 的用户进行身份验证。身份验证有助于防止未经授权的访问或滥用，避免这些行为给 API 及其连接的后端系统造成安全和性能方面的威胁。

Apigee 中的身份验证主要通过政策进行处理，政策就是 API 网关在处理传入请求时强制执行的规则。为了选择合理的身份验证政策，您需要评估自己的 API 和应用场景，并据此定制政策，以平衡安全性、易用性和简易性。

本文是解析 Apigee API 管理政策的系列博文的第二篇，我们将探索有助于防止未经授权的访问或滥用的各种身份验证政策。在深入探究这个话题之前，我们先介绍几个基本概念。

基础知识：身份、身份验证和授权

身份是指需要访问您的资源（例如 API、系统、服务等）的数字化用户帐号。用户帐号所代表的不一定是人类，也可能是软件、物联网设备或者机器人。

身份验证是指在授予 API 访问权限之前核实客户端或用户的数字化身份的过程。在身份验证期间，接受验证的人（或物）需要证明自己的身份与所声称的用户相符。

授权是确定用户有权访问哪些资源的过程。

身份提供方 (IdP) 是一种系统实体，负责创建、维护和管理身份信息并提供身份验证服务。

在 Apigee 中实现身份验证

通常情况下，身份验证的形式是要求客户端提供某种形式的凭据，比如用户名和密码、OAuth 令牌或者 JSON Web 令牌 (JWT)。作为 API 的所有者，您可以在 Apigee 中使用政策实现身份验证。具体来说，Apigee 中的安全性政策可用来对每个请求进行身份验证和授权，并保护您的内容。

Apigee 提供50 多种现成的政策。其中有一些不同的 API 身份验证政策，包括基本身份验证、OAuth 2.0、SAML、双向 SSL 身份验证和 API 密钥身份验证。在这篇博文中，我们将探索一些身份验证政策的功能、适合使用的场景以及如何根据您的应用需求实现这些政策。

您可以使用的不只有 Apigee 提供的一组政策类型。您还可以编写自定义脚本和代码（例如 JavaScript 应用和 Java），从而扩展 API 代理功能，在 Apigee 政策支持的基本管理功能的基础上创新。

根据您的 API 应用场景选择合适的身份验证方法

具体选择何种身份验证方法取决于 API 的要求以及 API 客户端或用户的需求。选择特定身份验证方法之前，从业者应厘清以下设计考虑事项

    1. 与 API 和客户端应用的兼容性：考虑客户端的问题 - 客户端是移动应用还是 Web 应用？是否需要断言？最终用户是否已授权应用代表其访问资源？

    2. 身份提供方：API 管理解决方案（比如 Apigee）通常提供少数现成功能，比如自动发放客户端凭据。但组织可能希望使用自定义功能管理用户身份，或者选择使用外部 IdP 来确保多个平台之间的一致性。

    3. 安全：不同的身份验证方法为 API 及其资源提供的安全保护水平各不相同。例如，假设您的 API 要处理敏感数据，那么您可能希望使用 OAuth 2.0 或双向 SSL 等较为强大的身份验证方法。

    4. 自助式新手入门支持：考虑身为实际使用者的开发者的新手入门流程。特别要考虑身份验证方法是否应为其提供自助式新手入门支持，帮助他们顺利上手 API。

    5. 最终用户身份验证：您的方法是否还应支持最终用户（仅限人类）身份验证调用？

    6. 开发者互动分析：您的身份验证方法是否还应该支持您捕获分析数据，以了解使用您的 API 的开发者和应用？

根据这些标准，我们确定了可在 Apigee 中实现的一些常用身份验证方法。在下表展示的框架中，您可以选择最适合您的 API 应用场景的身份验证方法。

1. API 密钥（仅用于识别）

要识别 API 客户端，最简单的一种方式就是使用 API 密钥。Apigee 内置的身份提供方可以发放客户端标识符，这可以用作 API 密钥，并通过现成的 VerifyAPIKey 政策加以验证。

API 密钥虽然简单易用，但要注意，这种机制只能用来识别传入请求。在不受信任的环境中，不应将它用作身份验证机制。API 密钥通常有效期较长，往往可从访问日志中读取，在工具中并未得到适当的遮盖。

2. OAuth2 令牌

OAuth2 是一种综合性业界标准，得到了 API 提供方的广泛采用。Apigee 支持多种不同类型的 OAuth2 授权（请参见其官方文档），大多数广泛适用的 Apigee 身份验证机制均使用 OAuth2 标准构建。

一种常见的实现方法就是使用 OAuth2 客户端凭据授权类型访问 API。在这种情景中，API 客户端使用其客户端 ID 和客户端密钥请求访问令牌。在后续调用受保护的端点时，系统就会使用该访问令牌对 API 客户端进行身份验证。访问令牌的发放和验证均可通过内置 Apigee 政策实现，如此处所述。

3. 外部令牌或断言

如果使用外部生成的令牌，Apigee 只会通过加密方式验证令牌是否由受信任的颁发者发放。Apigee 不参与发放令牌，也不会自动保留与 API 请求关联的应用、开发者或 API 产品的信息。

如果在特定情景中需要保留其中某些方面的信息，比如提供有关开发者互动的分析洞见，或者轻松将某个令牌的使用范围限制在特定 Apigee 环境内，那么就需要另行同步 Apigee 身份与在外部管理的身份。若要将外部管理的身份与 Apigee 资源关联起来，一种常用方法是通过自动化机制和 Apigee API 同步 Apigee 和外部 IdP。从技术角度上来讲，这表示可在第三方令牌声明中包含一个 Apigee 应用的客户端 ID 或 API 密钥，这样在通过 JWT 签名验证进行身份验证后，Apigee 代理就能识别客户端应用。

此外，对外部 IdP 的 /token 的 POST 请求可以通过 Apigee 进行代理，在外部创建的令牌可以通过 Apigee OAuth2 政策导入，并用于后续调用，如此处所述。

4. 令牌交换

在 Apigee 中可以使用 SAML（安全断言标记语言）断言，在身份提供方 (IdP) 与服务提供商 (SP) 之间交换令牌。SAML 是一种标准协议，支持在不同系统之间交换身份验证和授权数据。在令牌交换的背景下，SAML 断言是指已签名的 XML 文档，其中包含经过身份验证的用户的相关信息，例如其身份及其可能具备的任何授权权限。

令牌交换（说明请参见 RFC8693）的开始方式与上文所述的外部令牌方法相同。但在这种情况下，外部发放的令牌将交换为 Apigee 发放的令牌。将外部令牌或 SAML 断言交换为 Apigee 发放的令牌这一过程会额外增加一层信任，因为外部令牌仅用于通过经授权的应用获取 Apigee 令牌，而非直接访问资源 API。此外，如果在验证发起交换的客户端应用的客户端凭据后，您可以获得 Apigee 应用、开发者和 API 产品上下文，那么系统会自动为您提供这些上下文。

通过这种方式使用 SAML 断言交换令牌时，客户端应用可以利用现有身份验证系统，同时依然可以通过服务提供商访问受保护的资源。

5. 通过三方模式 OAuth 实现的身份 Facade

身份 Facade 是客户端应用与 OAuth 授权服务器之间的一层。其主要目的是将底层身份验证机制从客户端应用中抽象出来，让客户端不需要了解用户身份验证的具体实现细节。因此，开发者不需要熟悉 OAuth 协议的细节，从而能更轻松地构建支持 OAuth 的客户端应用。

除了抽象身份验证和授权机制之外，身份 Facade 还能提供其他服务，比如处理用户管理事务及提供额外的安全措施。但令牌交换（请参见先前部分中的解释）的主要缺点在于，将外部 IdP 令牌交换为 Apigee 令牌的负担由 API 使用者承担。使用者必须明确执行额外的调用，以实现令牌交换，并且要暂时持有外部令牌。

三方模式 OAuth 的身份 Facade 可以为外部令牌创建一个 Facade，从而避免这样的负担。这种 Facade 代理会调用令牌端点，随后创建一个与外部令牌关联、由 Apigee 发放的令牌。这样，Apigee 中的令牌验证就能保证外部令牌在流程中可用，进而可用于调用下游系统。

令牌通过 Facade 拦截，因此 API 客户端无法直接访问外部令牌，也就是说客户端无法通过直接调用后端和使用外部令牌来绕过 API 代理。从客户端的角度来看，Facade 性质透明，OAuth 流程看起来与其他任何授权代码流程都完全相同。

为了简化这种模式的实现，我们提供了一个参考实现，其中实现的身份 Facade 可用作任何符合 OIDC 规范的 IdP 的前端。

准备好在 Apigee 中使用身份验证政策了吗？

Apigee 为您提供了许多安全政策，本文所及仅为冰山一角。您甚至可以编写自定义脚本来扩展 API 代理功能，支持专门的应用场景。如需在 Apigee 中实现身份验证和其他安全政策的实操体验，请访问我们的 Skillsboost 实验，或者观看这场点播式 API 安全在线讲座。如需深入探究身份验证、参考架构并获得全面的示例，请访问我们的 GitHub 代码库。

文章信息

相关推荐