Question

我正在开发一个需要身份验证的REST API。因为身份验证本身是通过HTTP上的外部Web服务发生的，所以我推断我们会分配令牌以避免重复调用身份验证服务。这让我整整地回答了我的第一个问题：

这真的比仅要求客户端在每个请求上使用HTTP Basic Auth并缓存对身份验证服务服务器端的调用更好吗？

Basic Auth解决方案的优点是在开始内容请求之前不需要完整的服务器往返。令牌可能在范围上更灵活（即只对特定资源或操作授予权限），但这似乎比我更简单的用例更适合OAuth上下文。

目前获得的代币是这样的：

curl -X POST localhost/token --data "api_key=81169d80...
                                     &verifier=2f5ae51a...
                                     &timestamp=1234567
                                     &user=foo
                                     &pass=bar"

所有请求都需要api_key，timestamp和verifier。 “验证者”由以下人员返回：

sha1(timestamp + api_key + shared_secret)

我的意图是只允许来自已知方的电话，并防止电话被逐字重用。

这还够好吗？漏杀？矫枉过正吗

掌握令牌后，客户可以获得资源：

curl localhost/posts?api_key=81169d80...
                    &verifier=81169d80...
                    &token=9fUyas64...
                    &timestamp=1234567

对于最简单的电话，这看起来有点可怕。考虑到shared_secret将最终嵌入（至少）一个iOS应用程序，我认为它可以从中提取出来，这甚至提供了一种超出虚假安全感的东西吗？

Answer 1

让我分开一切，孤立地解决每个问题：

<强>验证

对于身份验证，baseauth的优势在于它是协议级别的成熟解决方案。这意味着很多“可能会突然出现”问题已经为您解决了。例如，使用BaseAuth，用户代理知道密码是密码，因此他们不会对其进行缓存。

验证服务器加载

如果您向用户分发令牌而不是在服务器上缓存身份验证，那么您仍然在做同样的事情：缓存身份验证信息。唯一的区别是您将缓存的责任转交给用户。对于没有收益的用户而言，这似乎是不必要的劳动，因此我建议您按照建议在服务器上透明地处理此问题。

传输安全性

如果可以使用SSL连接，那就是它的连接是安全的*。为防止意外多次执行，您可以过滤多个网址或要求用户在网址中包含随机组件（“nonce”）。

url = username:key@myhost.com/api/call/nonce

如果这是不可能的，并且传输的信息不是秘密的，我建议使用哈希来保护请求，正如您在令牌方法中所建议的那样。由于哈希提供了安全性，因此您可以指示用户提供哈希作为基本密码。为了提高稳健性，我建议使用随机字符串而不是时间戳作为“随机数”来防止重放攻击（在同一秒内可以进行两次合法请求）。您可以简单地使用api密钥作为共享密钥，而不是提供单独的“共享密钥”和“api密钥”字段，然后使用不会更改的salt来防止彩虹表攻击。用户名字段似乎也是放置nonce的好地方，因为它是auth的一部分。所以现在你有这样一个干净的电话：

nonce = generate_secure_password(length: 16);
one_time_key = nonce + '-' + sha1(nonce+salt+shared_key);
url = username:one_time_key@myhost.com/api/call

这确实有点费力。这是因为您没有使用协议级解决方案（如SSL）。因此，向用户提供某种SDK可能是个好主意，因此至少他们不必自己完成。如果你需要这样做，我发现安全级别合适（刚好 - 杀死）。

安全秘密存储空间

这取决于你试图挫败的人。如果您阻止访问用户手机的用户以用户名使用您的REST服务，那么最好在目标操作系统上找到某种密钥环API并让SDK（或实现者）存储关键在那里。如果这是不可能的，那么至少可以通过加密来保密，并将加密数据和加密密钥存储在单独的地方，从而使其变得更加困难。

如果您试图阻止其他软件供应商获取您的API密钥以阻止备用客户端的开发，那么只有加密和存储单独接近几乎才能正常工作。这是whitebox加密，到目前为止，还没有人为这类问题提出真正安全的解决方案。您至少可以为每个用户发出一个密钥，因此您可以禁止滥用密钥。

（*）编辑： 没有should no longer be considered secure的SSL连接taking additional steps to verify。

Answer 2

纯RESTful API应使用底层协议标准功能：

对于HTTP，RESTful API应符合现有的HTTP标准标头。添加新的HTTP标头违反了REST原则。不要重新发明轮子，使用HTTP / 1.1标准中的所有标准功能 - 包括状态响应代码，标题等。 RESTFul Web服务应该利用并依赖于HTTP标准。
RESTful服务必须是无状态的。尝试记住服务器上先前REST请求状态的任何技巧（例如基于令牌的身份验证）都违反了REST原则。再一次，这是必须的;也就是说，如果您的Web服务器在服务器上保存任何请求/响应上下文相关信息以尝试在服务器上建立任何类型的会话，那么您的Web服务不是无状态的。如果它不是无状态，则不是RESTFul。

底线：出于身份验证/授权目的，您应该使用HTTP标准授权标头。也就是说，您应该在每个需要进行身份验证的后续请求中添加HTTP授权/身份验证标头。 REST API应遵循HTTP身份验证方案标准。此标头应如何格式化的细节在RFC 2616 HTTP 1.1标准 - 第14.8节RFC 2616的授权和RFC 2617 HTTP身份验证：基本和摘要访问身份验证中定义

我为Cisco Prime Performance Manager应用程序开发了RESTful服务。在Google上搜索我为该应用程序编写的REST API文档，以获取有关RESTFul API合规性here的更多详细信息。在该实现中，我选择使用HTTP＆＃34; Basic＆＃34;授权方案。 - 查看该REST API文档的1.5或更高版本，并在文档中搜索授权。

Answer 3

在Web中，有状态协议基于在每个请求上具有在浏览器和服务器之间交换的临时令牌（通过cookie头或URI重写）。该令牌通常在服务器端创建，它是一段 opaque 数据，具有一定的生存时间，其唯一目的是识别特定的Web用户代理。也就是说，令牌是临时的，并且成为Web服务器在该对话期间代表客户端用户代理必须维护的状态。因此，以这种方式使用令牌的通信是STATEFUL。如果客户端和服务器之间的对话是STATEFUL，那么它不是RESTful。

用户名/密码（在Authorization标头上发送）通常持久保存在数据库中，目的是识别用户。有时用户可能意味着另一个应用;但是，用户名/密码 NEVER 旨在标识特定的Web客户端用户代理。基于在Authorization标头中使用用户名/密码（在HTTP基本授权之后）的Web代理和服务器之间的对话是STATELESS，因为Web服务器前端未创建或维护任何STATE 信息代表特定Web客户端用户代理的任何内容。根据我对REST的理解，协议明确指出客户端和服务器之间的对话应该是无状态的。因此，如果我们想拥有一个真正的RESTful服务，我们应该在每个调用的Authorization标头中使用用户名/密码（请参阅我在上一篇文章中提到的RFC），而不是一种感觉类型的令牌（例如在Web服务器中创建的会话令牌），在授权服务器中创建的OAuth令牌，等等。

据我所知，有几个名为REST的提供程序正在使用像OAuth1或OAuth2接受令牌这样的令牌作为HTTP授权中的“授权：承载”传递。但是，在我看来，使用这些令牌进行RESTful服务会违反REST所包含的真正的STATELESS;因为这些令牌是在服务器端创建/维护的临时数据片段，用于标识该Web客户端/服务器对话的有效持续时间的特定Web客户端用户代理。因此，如果我们想要坚持STATELESS协议的TRUE含义，那么使用这些OAuth1 / 2令牌的任何服务都不应被称为REST。

鲁

REST API基于令牌的身份验证

3 个答案: