那么，API 密钥到底是什么？它如何提供安全性？

我们将从标准定义开始：

API 密钥是一串字符串，用于识别和验证请求 API（应用程序编程接口）服务的应用程序或用户。

在本文中，我们为那些想了解 API 密钥是什么、做什么以及它是如何工作的内幕故事的好奇的人（技术人员或非技术人员）分解了这个定义。

API 密钥是让您进入的秘密代码

识别和认证

API 密钥是为其他应用程序提供服务的任何应用程序的标准安全机制。

虽然它们不是唯一的方法（API 可以使用 JWT，我们在这里写过： API 密钥与 JWT auth ） ，但API 密钥是保护 API 最常用的方法。

Google Maps API是需要 API 密钥的 API 服务（“端点”）的一个示例。如果您为 Google 的 API 提供物理地址（例如“1001 Main Street, NY, NY”），API 将返回最可能位置的纬度和经度（40.736124774992504、-73.82508447321075）。

但是，如果没有有效的 API 密钥，Google 将不会回复您的请求。您需要特别许可。 API 密钥让 Google 知道您是谁以及您是否有权访问他们的地图服务。

这称为身份验证（与授权相反，我们将在本文后面讨论。）

顺便说一下，为了理解这个机制是如何工作的，当我们写“我们给谷歌的 API 一个地址”或“我们向谷歌发送一个 API 密钥”时，我们指的是向谷歌服务器发送信息（发出请求通过 HTTP 请求方法（如 Post 和 Get）和接收信息（从同一 API 获取响应）。

总共：

如果开发人员想要使用 Google 几乎详尽的世界地址列表创建地图应用程序，他们将需要首先向 Google 注册并获得 API 密钥，以有权使用他们的 Google Map API 服务。

并非所有 API 都需要或使用 API 密钥

某些 API 不需要 API 密钥。例如，您用于观看视频的Youtube URL实际上是一个 API 请求，不需要 API 密钥。

所有人（不仅仅是开发人员）可以在世界任何地方、任何设备上免费使用它。

也就是说， Youtube 的 API还提供其他需要 API 密钥的服务，例如提供（私人或通常付费）有关频道播放列表、评论历史、使用统计信息以及数百个其他 Youtube 拥有的数据的服务。

易用性：API-First Thinking

任何 API 的一个核心问题是它的易用性。正如我们将在下面的安全性上下文中重复的那样：易用性对于 API 的使用至关重要。

所有 API 优先的公司都希望最大限度地减少使用其 API 产品的所有摩擦。这包括使访问他们的 API 变得容易和安全，这正是 API 密钥旨在提供的。

API 密钥——它们是如何工作的

如上所述，API 密钥使服务器能够识别任何试图访问其服务的开发者或应用程序（请求者或用户）。

API 密钥还定义了一组访问权限。访问权限授权请求者采取特定的行动并禁止它采取其他行动。

让我们进入细节。

您的 API 密钥是唯一标识符，通常是一长串字符

您的 API 密钥是由数字和字母组合而成的唯一标识符。有些还包含非字母数字字符。

唯一标识符本身并不表示任何东西；它的唯一意义是它的独特性。它类似于密码或密码。

API 密钥通常包含超过 64 个字符，由创建通用唯一标识符（通常称为GUID ）的系统随机生成器生成。

获取访问权限：身份验证或失败

将 API 密钥视为通过 API 访问应用程序数据和功能的一种方式。

每个 API 请求者都会向服务器发送一个唯一标识符，服务器使用该标识符来确定（验证）请求服务的人或应用程序是否有权这样做。

如果服务器无法验证 API 调用（请求）的请求者，它会发回失败响应。这是创建 API 密钥背后的基本思想：如果您使用服务器无法识别的密钥，那么您将无法使用该服务。

但是，如果服务器确实识别了 API 密钥并验证了密钥的持有者，则该用户有权使用该服务。

下一步是让服务器授权请求者做一件或多件事情。

授权

授权过程确定请求者的权利和范围。授权定义了经过身份验证的请求者可以使用 API 的确切方式。

它涉及定义您的权利（您可以访问哪些功能和数据）和范围（多少数据，您可以使用 API 多长时间等等）。

权利

权利是关于你能做什么。如果请求者的 API 密钥包含搜索数据的权限，则请求者可以读取数据来执行搜索。

如果请求者有权写入数据，则请求者可以执行部分或全部写入操作。写访问通常带有更多细节。例如，请求者可能有权更新索引但无权删除记录。

您还可以组合权限。例如，请求者可能同时具有读取和写入能力，或者只是只读的。通常，请求者有几个 API 来执行不同的操作。例如：

只读的搜索。

用于浏览和索引（添加、更新、删除）的读写访问。

管理员访问权限，包括所有内容，包括创建其他 API。

管理员权限

每个 API 系统都有一个全局 API 密钥，它不仅允许读写操作，还可以完全访问 API 可以执行的任何其他操作。

例如，管理 API 允许应用程序和用户执行元操作，例如添加、删除或修改用户、标识符、权限和范围。

鉴于 Admin API 密钥的强大功能，您将希望此 API 密钥完全安全——即隐藏并锁定在公众之外。

这同样适用于任何写入级别的 API 密钥。根据用例，只读键可能更灵活。读取业务敏感数据显然比在网站上搜索产品和电影需要更高的安全性。

范围

一旦请求者有权做某事，API 就可以在该权利范围内限制或扩展请求者的能力。例如，如果请求者具有更新索引的一般权限，则 API 密钥可以限制请求者仅访问某些索引。

或者，API 密钥可以限定只读访问权限，允许请求者仅访问少量记录。

您可以通过过滤掉某些 IP 地址来使用范围来进一步提高安全性。您还可以设置有效时间，可能是每天一个请求，或者在 30 天的时间段内每天处理少量请求。

最后，API 密钥可以提供基于过滤器的限制。例如，API 密钥可以允许用户仅更新“服装”或“食品”项目。或者它可以限制只读请求者执行预定义的搜索或过滤器。

关于限制性 API 使用的最后一点的一个很好的例子是您授予只读访问权限，但使用忽略敏感数据的过滤器来限制它。这增加了额外的安全性，允许请求者查看仅为公众查看而设计的数据。

但安全需要更多讨论。

保护 API 密钥

在安全性方面，API 密钥只能做到这一点。从本质上讲，如果密钥被盗或泄露，就没有更多的安全性了。

被盗或泄露的 API 密钥

有人可以通过多种方式获取 API 密钥。黑客可以拦截请求，窃取密钥，然后将请求更改为更具破坏性的内容。

或者，更常见的情况是，开发人员可能会通过将 API 密钥通过 Internet 发送，以便任何人轻松找到它，从而意外泄露 API 密钥。或者不小心将其推送到 Git 存储库。或者写在餐巾纸上，然后放在餐桌上。

安全保障

一些安全保护措施依赖于额外的安全检查。其中一些方法需要请求者做额外的工作，这会破坏 API 的流行度。值得牢记 API 101：

易用性对于 API 的使用至关重要，因此您希望最大限度地减少所有摩擦。

以下是一些不需要 API 用户额外开销或负担的安全保护措施：

创建速率限制，控制 API 可以调用的次数。

创建其他限制或应用程序限制以最大程度地减少攻击。

使用攻击检测方法发出意外行为、引荐来源或已知攻击行为的信号。

拒绝不符合规范或损害隐私或数据的请求。

如上所述，删除对非敏感数据的访问。

定期手动创建或自动生成新的 API 密钥。

技术说明：其中许多保护措施可以作为 API 请求中的参数添加到标头中。

以下是最流行的 API 安全技术，它们要求开发人员做的不仅仅是提供 API 密钥：

使用一种称为安全 API 密钥的特殊 API 密钥。

登录并使用用户 ID 和密码。

使用身份验证令牌（例如 JWT 令牌）进行身份验证和授权。

加密。为此，用户必须拥有与 API 服务器相同的加密软件。加密软件将 API 密钥转换为只有 API 服务器才能理解的不可读数据。

安全的 API 密钥：使用临时 API 密钥提供基于服务器的安全性

安全 API 密钥包含对标准 API 密钥的额外安全保护：(a) 它是短暂的（即时创建的和临时的）；因此，在仪表板上无法以任何方式对其进行修改或管理。

更重要的是，(b) 它包含用户的 id——因此，只有一个用户可以使用密钥。

通常，API 密钥为任何用户生成一次，并且终生保持不变。但是，永久密钥有两个缺点：

一旦有人窃取了密钥，他们将能够使用它，直到发现盗窃并移除密钥。

如果您需要 10,000 名用户拥有唯一的密钥，则需要创建并维护所有这些用户。虽然您可以自动生成新的 API 密钥，但您几乎总是需要手动更改代码。

大多数生产级应用程序需要更安全、更易于管理的东西——无需任何额外工作。

工作原理：安全 API 密钥通过将该信息作为密钥生成的一部分来利用会话和/或用户 ID。本质上，密钥是通过将用户标识符与密钥范围（例如，超时限制、安全过滤器）结合起来即时生成的。

生成密钥后，请求者必须始终发送生成的 API 密钥及其用户 ID 和范围。 API 服务器将使用用户 ID 和范围重新生成密钥，然后将其与用户发送的密钥进行比较。如果它们不同，那么这显然是一个 hack。

这种双重检查逻辑只是迈向更好安全性的一步。下一步是要求 API 用户登录。

登录——使用用户 ID、密码、JWT 令牌、OAuth 和 OpenID 创建 API 密钥

我们将在这里提到的最后一种安全方法涉及要求 API 用户登录。

在这种情况下，如果登录成功，API 服务器会发出一个唯一的、不可读的令牌，API 用户在保持登录状态时必须使用该令牌。此外，该令牌包括用户凭据，使得除用户之外的任何人都难以发送令牌。

因此，我们在两个重要方面改进了临时 Secured API Key 方法：

JWT 需要登录。

JWT 生成一个令牌，其值包含用户登录凭据的加密版本。这些用户凭证使 API 服务器能够使用每个连续的 API 请求对用户进行身份验证。

详细了解JWT 令牌以及它与 API 密钥的区别。

设计和实现最佳 API – 跟踪使用情况

我们已经讨论了 API 密钥的用途、它的外观、它的操作方式以及可以和不能使用 API 密钥完成的操作。

我们还详细介绍了安全性。我们将完成另一个方面：跟踪 API 使用和改进 API。

API 依赖于用户体验来改进其设计和功能。一家想要在竞争日益激烈的 API 市场中提供绝对最佳 API 的公司，必须了解其客户如何使用他们的 API。

通过记录每个请求——哪些请求、请求的数量、每个请求的成功和失败，API 提供者将报告、调试和分析添加到 API 的设计和实现中。