json - 简单、安全的 API 认证系统

Question

我有一个简单的 REST JSON API 供其他网站/应用程序访问我网站的一些数据库（通过 PHP 网关）。基本上该服务的工作方式如下：调用 example.com/fruit/orange，服务器返回有关橙子的 JSON 信息。问题是：我只希望我允许访问此服务的网站。使用简单的 API 密钥系统，任何网站都可以通过从授权网站的（可能的）客户端代码中复制密钥来快速获取密钥。我看过 OAuth，但我正在做的事情似乎有点复杂。解决方案？

Answer 1

您应该使用 OAuth。

实际上有两种 OAuth 规范，三足版和两足版。三足版是最受关注的，不是你想用的。

好消息是 2-legged 版本完全符合您的要求，它允许应用程序通过共享密钥授予对另一个应用程序的访问权限（非常类似于 Amazon 的 Web 服务模型，您将使用 HMAC-SHA1 签名方法）或通过公钥/私钥系统（使用签名方法：RSA-SHA1）。坏消息是，它还没有像 3-legged 版本那样得到很好的支持，所以你现在可能需要做更多的工作。

基本上，2-legged OAuth 只是指定了一种“签名”（计算散列）几个字段的方法，这些字段包括当前日期、一个称为“nonce”的随机数以及您的请求参数。这使得模拟对您的 Web 服务的请求变得非常困难。

OAuth 正在缓慢但肯定地成为这类事情的公认标准——如果你接受它，从长远来看，你会得到最好的结果，因为人们可以利用各种可用的库来做到这一点。

它比您最初想要的要复杂得多 - 但好消息是很多人在它上面花了很多时间，所以您知道您没有忘记任何东西。一个很好的例子是，最近 Twitter 发现了社区目前正在努力弥补的 OAuth 安全漏洞。如果您发明了自己的系统，那么您必须自己解决所有这些问题。

祝你好运！

克里斯

Answer 2

OAuth 不是这里的解决方案。
OAuth 是当您拥有最终用户并希望第 3 方应用程序不处理最终用户密码时。何时使用 OAuth： http ://blog.apigee.com/detail/when_to_use_oauth/

去简单的 api-key。
如果需要更安全的解决方案，请采取额外措施。

这是更多信息，http://blog.apigee.com/detail/do_you_need_api_keys_api_identity_vs._authorization/

Answer 3

如果某人的客户端代码被泄露，他们应该获得一个新密钥。如果他们的代码被公开，您将无能为力。

但是，您可以通过要求在您的系统中为给定密钥注册授权服务器的 IP 地址来更加严格。这增加了一个额外的步骤，可能是矫枉过正。

我不确定使用“简单 API 密钥”是什么意思，但您应该使用某种具有私钥的身份验证（仅客户端和服务器知道），然后对数据执行某种校验和算法以确保客户确实是您认为的那个人，并且数据在传输过程中没有被修改。 Amazon AWS就是一个很好的例子来说明如何做到这一点。

我认为保证代码没有在您的客户端受到损害可能有点严格。我认为让您的客户对自己的数据安全负责是合理的。当然，这假设攻击者只能弄乱该客户的帐户。

也许您可以记录某个特定帐户的 ip 请求来自哪些日志，如果出现新 ip，标记该帐户，向客户发送电子邮件，并要求他们授权该 ip。我不知道这样的事情可能会奏效。

Answer 4

基本上你有两个选择，要么通过 IP 限制访问，要么拥有 API 密钥，这两个选项都有其积极和消极的一面。

IP 限制
这可能是一种方便的方式来限制对您的服务的访问。您可以准确定义哪些 3rd 方服务将被允许访问您的服务，而无需强制它们实施任何特殊的身份验证功能。然而，这种方法的问题是，如果 3rd 方服务是完全用 JavaScript 编写的，那么传入请求的 IP 将不是 3rd 方服务的服务器 IP，而是用户的 IP，因为发出请求由用户的浏览器而不是服务器。因此，使用 IP 限制将无法编写客户端驱动的应用程序，并强制所有请求通过具有适当访问权限的服务器。请记住，IP 地址也可能被欺骗。

API 密钥 API 密钥
的优点是您不必维护已知 IP 的列表，您必须维护 API 密钥列表，但自动化维护更容易。基本上它的工作原理是你有两个密钥，例如一个用户 ID 和一个秘密密码。对您的服务的每个方法请求都应提供一个由请求参数、用户 ID 和这些值的哈希组成的身份验证哈希（其中秘密密码用作哈希盐）。这样，您既可以进行身份​​验证，也可以限制访问。问题在于，如果第 3 方服务被编写为客户端驱动（例如 JavaScript 或 ActionScript），那么任何人都可以从代码中解析出用户 ID 和秘密盐值。

基本上，如果您想确保仅允许您专门定义的少数服务访问您的服务，那么您唯一的选择是使用 IP 限制，从而强制它们通过其服务器路由所有请求。如果您使用 API 密钥，则无法强制执行此操作。

Answer 5

在连接之前，IP 安全性的所有生产似乎都会对用户产生巨大的错误。Symbian 60s 具有在多个用户（应用 Opera Handler UI 6.5、Opera Mini v8 和 10）以及编码 UI 和完全填充的网络设置中留下未追踪、可靠和安全信号的最完整功能。当最终获得可发现的快速链接方法时，为什么要限制其他特征。保持一个更明确的账户，正确监控那个“真实账户”——如果他们在支付账单的轨道上——并知道用户是否有未过期的维持余额，这将创建一个更快的互联网信号链接到流行/签名的移动设备行业。为什么要在将它们带到站点之前制作硬安全功能，每月访问他们的帐户可能会消除所有连接问题？如果他们有未付的账单，所有移动用户都应该没有“连接”的能力。为什么不提供一个“ALL in One” - 注册/应用程序帐户，一个由操作系统修复的程序，（可能是一个电子邮件帐户），而不是提供一个“监控功能”，如果他们支付与否（密码问题问题应该给出到其他部门）。如果“不”完全关闭他们的帐户和其他链接功能。他们每个人都有自己的兴趣每天在哪里上钩，如果您因未付账单而锁定/关闭它们，这可能会促使他们重新订阅并更多地训练他们以成为更负责任的用户，甚至可能过期如果没有维护一个帐户。每月监控或访问已识别的 ' 与网络提供商合作的“真实帐户”可以产生更高的隐私，而不是总是要求用户提供“姓名”和“密码”、“位置”、“权限”来查看他们的数据服务。IP 已经标记了他们的第一个身份或“查找用户的位置”，因此，将其放在浏览器预搜索中似乎是不必要的，为什么不使用“获取数据”或“处理数据”。