未经用户许可的 API 的 OAuth 设计答案

【问题标题】：OAuth design for API without users permission未经用户许可的 API 的 OAuth 设计
【发布时间】：2011-03-23 02:02:52
【问题描述】：

我正在开发一个可供我的客户的用户使用的 API。流程如下所示：

我正在寻求有关如何保护此 API 的建议。我发现了一些问题：

有人对如何设计这个有任何想法吗？

【问题讨论】：

您的问题 1：必须嵌入 API 密钥...这是为什么呢？您使用什么语言/平台？
API 不能完全开放。我代表我的系统用户从应用程序收集信息。所以我需要确保这些信息是合法的，并且它进入了我们系统中的正确账户。这有意义吗？
Eric，你最终是如何很好地实现这一点的？我能想到的每一种保护 API 的方法都需要某种形式的公钥/私钥，而这些公钥/私钥都会受到这种安全漏洞的影响。我特别想到了今年早些时候下载/转发的那些带有恶意软件的 Android 应用程序。 FWIW，Twitter 似乎通过为每个应用程序而不是每个帐户发布公钥/私钥来解决这个问题，所以如果一个应用程序受到攻击，整个应用程序将被关闭，直到推出具有新密钥的新版本出去。 dev.twitter.com/pages/auth
每个客户都获得了他们产品的公共 api 密钥，他们尽最大努力保证这个 api 密钥的安全，但要保证它完全安全是不可能的。因此，当应用程序请求允许将案例提交到我们的 API 时，他们会出示该 API 密钥，然后他们会收到一个 oauth 令牌作为交换。我们跟踪可能滥用我们的任何 IP，并且我们使用 SSL 进行所有通信。用户还可以禁用和创建新的 API 密钥。这似乎是我们能做的最好的了。
埃里克，感谢您的澄清。听起来是一种完全合理（且安全）的方法。

标签： api oauth

【解决方案1】：

我可能弄错了，但也许您可以让客户的用户与客户的 API 对话。基本上，您的客户会将他们的密钥保存在他们的服务器上，而不是将它们嵌入到他们提供给用户的客户端中，因此它不会被劫持（当然，除非他们的服务器被入侵）。然后用户将通过您客户的 API 与您的 API 对话。

这会更慢，需要您的客户做更多的工作，但也更安全。

【讨论】：

【解决方案2】：

我可以看到两个解决方案，虽然我确信还有更多..

这两者都不容易，并且需要用户的应用程序“打电话回家”才能更新他们的消费者密钥。

我认为未来 OAuth 2 至少会为此类事情提供协议定义，但目前，如果您使用的是 OAuth 1.0a，那么您想要做的事情并不能很好地符合规范（即你必须自己设计大部分内容。）

【讨论】：

既然应用程序被分发给一群不受信任的用户，他们中的任何一个人都不能简单地反编译应用程序并获取消费者和密钥并能够滥用服务吗？我想不出一种方法可以防止这种类型的滥用。我唯一能想到的就是能够阻止滥用服务的 IP。