我目前正在为我们的网络服务构建RESTful API，第三方网站和移动应用将访问该服务。我们希望对API使用者（即那些Web和移动应用程序）具有一定程度的控制权，因此我们可以执行API请求限制和/或阻止某些恶意客户端。为此，我们希望每个将访问我们API的开发人员从我们这里获取API密钥并使用它来访问我们的API端点。对于某些未处理特定用户信息的API调用，这是唯一需要的身份验证级别。授权，我称之为“app”-level A＆amp; A.但是，某些API调用处理属于特定用户的信息，因此我们需要一种方法来允许这些用户登录并授权应用程序访问其数据，从而创建第二级（或“用户”级别A＆amp; A） 。
将OAuth2用于“用户”级A＆amp; A是很有意义的，我想我对这里需要做的事情有很好的了解。
我还实现了类似OAuth1的方案，其中app开发者会收到一对API密钥和＆amp;秘密，每次调用都提供他们的API密钥，并使用秘密来签署他们的请求（同样，它非常像OAuth1，我应该只使用OAuth1）。
现在我遇到的问题是如何将这两种不同的机制结合起来。我目前的假设是我继续使用API密钥/密钥对来签署所有能够访问所有API端点的请求，对于那些需要访问用户特定信息的呼叫，应用需要通过OAuth2流并获取访问权限并提供它们。
所以，我对社区的问题是 - 这听起来是一个很好的解决方案，还是有一些更好的方法来构建它。
我也很欣赏我可以使用的现有解决方案的任何链接，而不是重新发明轮子（我们的服务是基于Ruby / Rails的）。
答案 0 :(得分：0)
您的密钥/密钥对并不能真正让您对移动应用程序的作者有信心。秘密将嵌入可执行文件中，然后提供给用户，并且您无法阻止用户提取密钥。
在Stack Exchange API中，我们只使用OAuth 2.0并接受我们所能做的就是切断滥用用户（或IP，在没有OAuth的早期版本中）。我们确实提供了用于跟踪目的的密钥，但它们并不是秘密（并且没有任何价值，因此没有动机去窃取它们。）
在防止滥用方面，我们所做的是在没有身份验证令牌的情况下基于IP进行节流，但是当有用户时，切换到每用户节流。
在处理纯粹的恶意客户时，我们会释放律师（在我们的案例中，恶意几乎总是违反cc-wiki指南）;技术解决方案在我们的估算中并不够复杂。请注意，恶意客户端的发生率实际上非常低（多年运行中的个位数，每天有数百万个API请求）。
简而言之，我放弃了OAuth 1.0并将您的限制切换为基于IP和用户的混合。