商户密钥和api密钥_构建安全API密钥的最佳做法

最新推荐文章于 2024-03-13 10:55:38 发布

cumifi2519

最新推荐文章于 2024-03-13 10:55:38 发布

阅读量1.4k

点赞数

文章标签： java 数据库 python mysql 大数据

原文链接：https://www.freecodecamp.org/news/best-practices-for-building-api-keys-97c26eabfea9/

版权

商户密钥和api密钥

by Ramesh Lingappa

通过拉梅什·林加帕(Ramesh Lingappa)

构建安全API密钥的最佳做法 (Best practices for building secure API Keys)

We all know how valuable APIs are. They’re the gateway to exploring other services, integrating with them, and building great solutions faster.

我们都知道API的价值。它们是探索其他服务，与之集成以及更快地构建出色解决方案的门户。

You might have built or are thinking of building APIs for other developers to use. An API needs some form of authentication to provide authorised access to the data it returns.

您可能已经构建或正在考虑构建供其他开发人员使用的API。 API需要某种形式的身份验证，以提供对其返回的数据的授权访问。

There are several authentication standards available today such as API Keys, OAuth, JWT, etc.

今天有几种认证标准可用，例如API密钥， OAuth ， JWT等。

In this article, we’ll look at how to correctly manage API Keys to access APIs.

在本文中，我们将研究如何正确管理API密钥以访问API。

那么为什么要使用API密钥？ (So Why API Keys?)

API Keys are simple to use, they’re short, static, and don’t expire unless revoked. They provide an easy way for multiple services to communicate.

API密钥易于使用，且简短，静态，并且除非被撤消，否则不会过期。它们为多种服务提供了一种简便的通信方式。

If you provide an API for your clients to consume, it’s essential for you to build it in the right way.

如果您提供API供客户使用，则以正确的方式构建它至关重要。

Let’s get started, and I’ll show you how to build API Keys the right way.

让我们开始吧，我将向您展示如何正确构建API密钥。

API密钥生成 (API Key Generation)

Since the API key itself is an identity by which to identify the application or the user, it needs to be unique, random and non-guessable. API keys that are generated must also use Alphanumeric and special characters. An example of such an API key is zaCELgL.0imfnc8mVLWwsAawjYr4Rx-Af50DDqtlx.

由于API密钥本身是用于标识应用程序或用户的身份，因此它必须是唯一，随机且不可猜测的。生成的API密钥还必须使用字母数字和特殊字符。此类API密钥的示例是zaCELgL.0imfnc8mVLWwsAawjYr4Rx-Af50DDqtlx 。

安全的API密钥存储 (Secure API Key Storage)

Since the API key provides direct access to data, it’s pretty much like a password that a user of a web or mobile app provides to gain access to the same data.

由于API密钥可直接访问数据，因此它很像Web或移动应用程序的用户提供的用于访问相同数据的密码。

Think about it. The reason we need to store API keys is to make sure that the API key in the request is valid and issued by us (just like a password).

想一想。我们需要存储API密钥的原因是，确保请求中的API密钥是有效的并由我们发出(就像密码一样)。

We don’t need to know the raw API key, but just need to validate that the key is correct. So instead of storing the key in plain text (bad) or encrypting it, we should store it as a hashed value within our database.

我们不需要知道原始的API密钥，而只需要验证密钥是否正确即可。因此，我们应该将密钥作为哈希值存储在数据库中，而不是将密钥存储为纯文本(错误的)或对其进行加密。

A hashed value means that even if someone gains unauthorised access to our database, no API keys are leaked and it’s all safe. The end user would send the raw API key in each API request, and we can validate it by hashing the API key in the request and compare the hashed key with the hash stored within our database. Here is a rough implementation of it in Java:

哈希值表示即使有人获得了对我们数据库的未经授权的访问，也不会泄漏任何API密钥，这一切都是安全的。最终用户将在每个API请求中发送原始API密钥，我们可以通过对请求中的API密钥进行哈希处理并将其与数据库中存储的哈希进行比较来对其进行验证。这是在Java中的粗略实现：

In the code above, the primary key will be a combination of the prefix and the hash of the API key {prefix}.{hash_of_whole_api_key}.

在上面的代码中，主键将是API密钥{prefix}.{hash_of_whole_api_key}的前缀和哈希值的组合。

But hold on, there is more. Storing a hashed value brings specific usability problems. Let’s address those now.

但是等等，还有更多。存储散列值会带来特定的可用性问题。让我们现在解决这些。

向用户展示API密钥 (Presenting the API Key to users)

Since we don’t store the original API key, we can show it only once to the user, at the time of creation. So be sure to alert users that it cannot be retrieved again, and they need to generate a new token if they forget to copy the API key and store it safely. You can do something like this:

由于我们不存储原始API密钥，因此在创建时只能向用户显示一次。因此，请确保警告用户无法再次检索它，如果他们忘记复制API密钥并安全地存储它，则需要生成一个新令牌。您可以执行以下操作：

用户以后如何识别生成的API密钥 (How users can identify a generated API Key later)

Another problem is how users identify the right API key in your console if they need to edit or revoke it. This can be solved by adding a prefix to the API key. Notice in the picture above the first 7 characters (that’s our prefix), separated by the dot.

另一个问题是，如果用户需要编辑或撤消它，则如何在控制台中识别正确的API密钥。这可以通过在API密钥上添加前缀来解决。请注意图片中的前7个字符(这是我们的前缀)，以点分隔。

Now you can store this prefix in the database and display it in the console so users are able to quickly identify the right API key entry, like this:

现在，您可以将此前缀存储在数据库中并在控制台中显示，以便用户能够快速识别正确的API密钥条目，如下所示：

不要给API密钥所有权力 (Don’t give the API Key all the power)

One common mistake that API key providers make is providing one key to access everything, since it’s easy to manage. Don’t do that. Assume that a user just needs to read an email, and generates an API key. But that key now has full access to other services, including deleting records in the database.

API密钥提供程序犯的一个常见错误是提供一个密钥来访问所有内容 ，因为它易于管理。不要那样做假设用户只需要阅读一封电子邮件，并生成一个API密钥。但是，该密钥现在可以完全访问其他服务，包括删除数据库中的记录。

The right approach is to allow the end users to properly restrict API Key access and choose specific actions that an API key can carry out. This can be done by providing scopes, where each scope represents a specific permission.

正确的方法是允许最终用户适当地限制对API密钥的访问，并选择API密钥可以执行的特定操作。这可以通过提供作用域来完成，其中每个作用域代表一个特定的权限。

For example,

例如，

if you need an API key to just send emails, you can generate an API key with the scope as “email.send”
如果您只需要一个API密钥即可发送电子邮件，则可以生成范围为“ email.send”的API密钥
if the end user has multiple servers and each carries out a specific action, then a separate API key can be generated with a specific scope.
如果最终用户有多个服务器，并且每个服务器都执行特定的操作，则可以生成具有特定范围的单独的API密钥。

So while creating the API key, allow users to select what access that API key should have, as in the image below.

因此，在创建API密钥时，允许用户选择该API密钥应具有的访问权限，如下图所示。

This way users can generate multiple API keys, each with specific rules of access for better security. And when an API request is received, you can check if the API Key has the right scope to access that API. Now the database looks something like this:

这样，用户可以生成多个API密钥，每个密钥都有特定的访问规则，以提高安全性。并且，当收到API请求时，您可以检查API密钥是否具有访问该API的正确范围。现在数据库看起来像这样：

限速API密钥 (Rate limiting API keys)

Yes, you might already know it, but it is important to rate limit requests made with specific API Keys to ensure no bad actor can take down your API servers or cause performance issues that affect your other customers. Having a proper rate limiting and monitoring solution keeps the API service healthy.

是的，您可能已经知道这一点，但是对使用特定API密钥发出的请求进行速率限制很重要，以确保没有不良行为者可以关闭您的API服务器或导致影响其他客户的性能问题。拥有适当的速率限制和监视解决方案可使API服务保持健康。

结论 (Conclusion)

API keys, when built right, are still a great way to communicate with another server. As we reviewed in this article, following certain practices offers benefits to both API consumers and API providers. Hope this helps you.

正确构建API密钥后，仍然是与另一台服务器通信的好方法。正如我们在本文中所回顾的那样，遵循某些惯例可以为API使用者和API提供者带来好处。希望对您有帮助。

Happy Securing your APIs!

祝您的API安全！