我写了一个Web应用程序，我想允许其他开发人员从它那里得到的信息。
进出口工作在服务器上是不是棒极了和无法处理如此之多的要求，这样的想法是生成和分配API密钥给大家，希望我们的查询信息。 随着API密钥我可以限制每天的请求，并可能收集一些统计数据，看看什么样的信息是对其他开发人员非常有用。
问题是，即时通讯担心它的安全性方面。 由于API密钥将被发送到我们的服务器（通过GET / POST等），有人可以嗅出使用Wireshark的请求，并得到毫不费力地开发API密钥，对不对？
我想过生成密钥和API密钥。 然后，我可以指导其他开发人员将它们串联并发送它的散列我们的API。 然后我会验证散列是有效的，并允许请求......但后来同样的问题会持续存在。 黑客可以嗅出仍然散列，并代表其他开发者的应用程序的请求。
所以我的问题是
你们有什么感想？
我想你想在这里解决了一堆不同的问题。
如果你的目标是限制请求到服务器的数量，你应该创建一个限制机制。 这是不平凡的，但我想它的基础上的IP地址，而不是许可密钥 - 一个授权用户可能会淹没你的系统有很多的请求。 您可以通过IP地址，而无需实施许可证机制油门。
如果你想创建一个授权方案，你需要了解加密等 - 这是一个不平凡的问题。 举例来说，你如何阻止合法用户与所有的朋友分享他们的许可证密钥？ 你如何阻止窃取您的钥匙，并与所有的朋友分享这是黑客？
有许多这种解决方案 - 他们都强加给你的用户一定程度的疼痛。 例如，你可以在HTTPS运行服务; 这将停止监听，但会降低性能。 您可以发出你的服务，使用一定次数后到期“令牌”; 获得新令牌需要一个密码交换（这可能会检查你的IP地址）。 你可能需要一个“挑战/响应”类型的逻辑（包括IP地址验证）。 所有这些步骤为您的用户的生活困难; 他们可能不会感谢你多的他们需要做额外的工作。
对于嗅，你的问题可以与您的服务器上HTTPS来解决。
它肯定是有道理的把一些认证的API，如果你想限制访问+潜在的一些使用率高的限制。 如果您使用的API密钥，并希望避免嗅探然后HTTPS肯定是要走的路。 如果这不是一个选项，然后你也可以使用一个散列式身份验证样的OAuth 1.0（http://oauth.net/core/1.0/）或亚马逊AWS认证。 这些作品用一个ID和一个秘密发布您的API用户。 他们通过将其插入消息主体中，计算的散列和在请求中包括的散列（不是秘密）使用在客户端的秘密。 在进入方面，你比较与他们的具体包含秘密信息内容进行相同的操作哈希值。
这意味着，你可以验证发件人，而无需通过网络发送的秘密（注意，内容仍然是不安全的 - 但你避免将主要通过线路的每个请求）。 不足之处是它的复杂，开发人员能够实现。 即使您使用OAuth 1.0模式，其中有库这是一个有点开销。
我在3比例的工作和我们的一些工具可能也是有帮助的-我们的系统提供API密钥，OAuth的秘密共享，也API速率限制开箱（http://www.3scale.net和PHP库在这里： HTTPS ：//github.com/3scale/3scale_ws_api_for_php ）。
