RESTful API 的双重身份验证

Question

我目前正在为我们的 Web 服务构建一个 RESTful API，该 API 将由 3rd 方 Web 和移动应用程序访问。我们希望对 API 消费者（即那些 Web 和移动应用程序）有一定程度的控制，因此我们可以对 API 请求进行限制和/或阻止某些恶意客户端。为此，我们希望每个将访问我们的 API 的开发人员都从我们这里获取一个 API 密钥并使用它来访问我们的 API 端点。对于一些不处理特定用户信息的 API 调用，这是唯一需要的身份验证和授权级别，我称之为“应用程序”级别的 A&A。但是，一些 API 调用处理属于特定用户的信息，因此我们需要一种方法来允许这些用户登录并授权应用程序访问他们的数据，从而创建第二级（或“用户”级 A&A）。

将 OAuth2 用于“用户”级别的 A&A 非常有意义，我认为我非常了解我需要在这里做什么。

我还实现了类似 OAuth1 的方案，其中应用程序开发人员会收到一对 API 密钥和密钥，在每次调用时提供他们的 API 密钥并使用密钥来签署他们的请求（同样，它非常类似于 OAuth1，我应该只使用OAuth1）。

现在我遇到的问题是如何结合这两种不同的机制。我目前的假设是，我继续使用 API 密钥/密钥对来签署所有请求，以便能够访问所有 API 端点，并且对于那些需要访问用户特定信息的调用，应用程序将需要通过 OAuth2 流程并获取访问令牌并提供给他们。

所以，我向社区提出的问题是 - 这听起来像是一个好的解决方案还是有一些更好的方法来构建它。

我也很感激任何指向我可以使用的现有解决方案的链接，而不是重新发明轮子（我们的服务基于 Ruby/Rails）。

Answer 1

您的密钥/密钥对并没有真正让您对移动应用的作者身份有任何信心。密钥将嵌入到可执行文件中，然后提供给用户，您实际上无法阻止用户提取密钥。

在 Stack Exchange API 中，我们只使用 OAuth 2.0 并接受我们所能做的就是切断滥用用户（或 IP，在没有 OAuth 的早期版本中）。我们确实提供了用于跟踪目的的密钥，但它们不是秘密的（并且不提供任何有价值的东西，因此没有动机窃取它们）。

在防止滥用方面，我们所做的是在没有身份验证令牌的情况下基于 IP 进行限制，但在有身份验证令牌时切换到每个用户的限制。

在与纯粹的恶意客户打交道时，我们会动用律师（在我们的案例中，恶意几乎总是违反 cc-wiki 准则）；在我们的估计中，技术解决方案还不够复杂。请注意，恶意客户端的发生率非常低（运营年限为个位数，每天有数百万次 API 请求）。

简而言之，我会放弃 OAuth 1.0 并将您的节流阀切换到 IP 和基于用户的混合体。