支持我们自己的限速API

Question

概述：

我的公司开发了一个限速API。我们的目标有两个：

• A:围绕我们的产品创建一个强大的开发人员生态系统。
• B:通过使用它来驱动我们自己的应用程序来展示我们的应用程序接口的威力。

澄清:为什么要进行速率限制？

我们限制API的价格，因为我们将其作为产品的附加产品出售。匿名访问我们的API每小时的API调用门槛非常低，而我们的付费客户每小时允许调用1000次或更多。

The Problem:

我们的速率限制API对于开发者生态系统来说是很棒的，但是为了让我们给它喂食，我们不能允许它被限制在相同的速率限制下。我们的应用程序接口的前端都是JavaScript，对该应用程序接口进行直接Ajax调用。

所以问题是：

如何保护应用编程接口，使速率限制可以被移除，在移除过程中，这种速率限制在哪里不能被轻易地欺骗？

探索了解决方案(以及为什么它们不起作用)

1. 根据主机标头验证referrer。--有缺陷，因为referrer很容易伪造。
2. 使用HMAC根据请求和共享密钥创建签名，然后在服务器上验证请求。--有缺陷，因为秘密和算法很容易通过查看前端JavaScript.
3. Proxy请求并在代理中签名来确定-仍然有缺陷，因为代理本身暴露了API。

问题：

我期待着Stack和Overflow上的才华横溢的人提出替代解决方案。你将如何解决这个问题？

Answer 1

由于您自己的JavaScript客户端直接访问该应用程序接口，因此任何人都可以查看它所做的事情并对其进行模拟，包括使用相同的API键。你可以试着让它变得更困难，比如混淆你的代码，或者设置各种障碍，但是你和你试图约束的人基本上拥有相同的访问权限。您需要构建一个系统，在这个系统中，非官方客户端使用其作用域中的所有访问权限是完全可以的，但系统的安排方式是所有客户端的官方使用量更大，而不是试图在特权之间创建不同的权限。

这通常是通过每个用户的访问令牌来完成的，而不是整个应用程序使用一个令牌。对于API的典型使用来说，每个令牌的限制应该足够了，但对于试图滥用它的人来说，则是有限制的。例如，每分钟100个呼叫可能足以支持典型的浏览，但如果我想刮你，我不能在这个预算内有效地做到这一点。

总会有一场军备竞赛--我可以通过创建大量的机器人用户帐户来绕过这个限制。然而，如果你只是在你的注册流程中添加验证码，这是一个很好的解决问题，对真正的人类来说，这是一个很小的代价。当您进入这些场景时，一切都只是在方便和限制之间进行权衡。你永远不会找到完全防弹的东西，所以专注于把它做得足够好，等到有人利用你来了解漏洞在哪里。

Answer 2

如果这给你带来了问题，它也会给你假定的开发人员生态系统带来问题(例如，当他们试图开发一个替代UI时)。如果您真的在吃自己的狗粮，那么让API (和速率限制)适用于您的应用程序。以下是一些建议：

• 不按IP地址限制速率。相反，通过与用户相关的内容进行速率限制，例如他们的用户ID。在身份验证阶段应用速率限制。
• 设计您的应用程序接口，使用户不需要连续调用它(例如，进行返回许多结果的列表调用，而不是每次返回一个项目的重复调用)
• 使用您期望开发人员生态系统具有的相同约束来设计您的web应用程序。
• 确保你的后端是可伸缩的(最好是水平的)，这样你就不需要在太低的水平上施加节流，以至于实际上会对UI造成问题。
• 确保你的节流能够应对突发事件，并限制较长的时间。
• 确保你的节流执行针对你正在寻求消除的滥用而量身定做的合理操作。例如，考虑排队或延迟轻度滥用者，而不是拒绝连接。大多数web前端一次只能同时打开四个连接。如果你延迟了打开第五个客户端的尝试，你只会遇到这样的情况:他们同时使用CLI作为web客户端(或两个web客户端)。如果您在没有间隙的情况下延迟第n个API调用，而不是失败，最终用户将看到事情变慢而不是中断。如果你把它和一次只排队N个应用程序接口调用结合起来，你只会打击那些正在并行处理大量应用程序接口调用的人，这可能不是你想要的行为--例如，100个同时进行的应用程序接口调用，那么一个小时的间隔通常比一个小时内100个连续的应用程序接口调用要糟糕得多。

这还没有回答你的问题吗？好吧，如果你真的需要做你所要求的，在认证阶段进行速率限制，并根据你的用户所在的组应用不同的速率限制。如果您使用一组凭据(由您的开发人员和QA团队使用)，您将获得更高的速率限制。但是您可以立即看到为什么这将不可避免地将您引导到您的生态系统，看到您的开发人员和QA团队没有看到的问题。

Answer 3

购买你的产品。成为你自己的付费客户。

匿名访问我们的API的门槛非常低，而我们的付费客户每小时允许调用1000次或更多。“

这也有助于从客户的角度测试系统。