问基于REST API令牌的身份验证

EN

让我把所有的东西分开，然后孤立地解决每个问题：

Authentication

对于身份验证，baseauth的优势在于它在协议层是一个成熟的解决方案。这意味着很多“以后可能会出现”的问题已经为你解决了。例如，使用BaseAuth时，用户代理知道密码是密码，因此不会缓存它。

身份验证服务器加载

如果您将令牌分发给用户，而不是在服务器上缓存身份验证，那么您仍然在做同样的事情:缓存身份验证信息。唯一的区别是，您将缓存的责任推给了用户。对于用户来说，这似乎是不必要的工作，没有任何好处，所以我建议按照您的建议在服务器上透明地处理它。

传输安全

如果可以使用SSL连接，那就是所有的连接，连接是安全的。为了防止意外的多次执行，您可以过滤多个URL，或者要求用户在URL中包含一个随机组件("nonce")。

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

如果这是不可能的，并且传输的信息不是秘密的，我建议使用散列来保护请求，就像您在令牌方法中建议的那样。由于散列提供了安全性，因此您可以指示用户提供散列作为baseauth密码。为了提高健壮性，我建议使用随机字符串而不是时间戳作为“现时值”，以防止重放攻击(可以在同一秒内发出两个合法请求)。不需要提供单独的“共享密钥”和"api密钥“字段，只需使用api密钥作为共享密钥，然后使用不变的盐，以防止彩虹表攻击。用户名字段似乎也是放置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可能是一个好主意，这样他们至少不必自己经历它。如果您需要这样做，我认为安全级别是合适的(just-right-kill)。

安全机密存储

这取决于你试图阻挠的是谁。如果您要阻止有权访问用户电话的人以用户的名义使用您的REST服务，那么在目标操作系统上找到某种密钥环API并让SDK (或实现者)将密钥存储在目标操作系统上将是一个好主意。如果这是不可能的，你至少可以通过加密它，并将加密的数据和加密密钥存储在不同的地方，从而使获取秘密变得更加困难。

如果您试图阻止其他软件供应商获得您的API密钥，以防止开发替代客户端，那么只有加密和存储分离的方法几乎是有效的。这是白盒加密，到目前为止，还没有人想出一个真正安全的解决方案来解决这类问题。您至少可以为每个用户颁发一个密钥，这样您就可以禁止滥用密钥。

(*) EDIT: SSL connections without The.

纯RESTful应用程序接口应该使用底层协议标准特性：

对于HTTP的

• ，RESTful接口应该符合现有的HTTP标准头。添加新的HTTP头违反了REST原则。不要重复发明轮子，使用HTTP/1.1标准中的所有标准特性-包括状态响应码、标头等。HTTP服务应该利用并依赖于standards.

• RESTful服务必须是无状态的。任何技巧，比如试图记住服务器上以前REST请求状态的基于令牌的身份验证，都违反了REST原则。同样，这也是必须的；也就是说，如果您的web服务器将任何与请求/响应上下文相关的信息保存在服务器上，以尝试在服务器上建立任何类型的会话，那么您的web服务就不是无状态的。如果它不是无状态的，那么它就不是RESTFul。

底线:出于身份验证/授权的目的，您应该使用HTTP标准的authorization头。也就是说，您应该在每个需要进行身份验证的后续请求中添加HTTP授权/身份验证头。REST API应遵循HTTP Authentication Scheme standards.The，有关如何格式化此报头的详细信息，请参阅RFC2616HTTP1.1标准-RFC2616的14.8授权，以及RFC2617HTTP验证:基本和摘要访问验证。

我已经为Cisco Prime Performance Manager应用程序开发了RESTful服务。在谷歌上搜索我为该应用程序编写的REST API文档，了解有关RESTFul API遵从性here的更多详细信息。在实现中，我选择使用HTTP“基本”授权方案。-检出REST API文档的1.5版或更高版本，并在文档中搜索授权。

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

用户名/密码(在Authorization头上发送)通常保存在数据库中，目的是识别用户。有时，用户可能表示另一个应用程序；但是，用户名/密码永远不会用于标识特定的web客户端用户代理。web代理和服务器之间基于使用Authorization标头中的用户名/密码(在HTTP Basic Authorization之后)的会话是无状态的，因为web服务器前端不会代表特定的web客户端用户代理创建或维护任何状态信息。根据我对REST的理解，该协议明确规定客户端和服务器之间的会话应该是无状态的。因此，如果我们想要有一个真正的RESTful服务，我们应该在每个单独的调用的授权头中使用用户名/密码(请参考我上一篇文章中提到的RFC )，而不是sension类型的令牌(例如，在web服务器中创建的会话令牌，在授权服务器中创建的OAuth令牌，等等)。

据我所知，一些被调用的REST提供者正在使用像OAuth1或OAuth2 accept这样的令牌--令牌在HTTP头中作为"Authorization: Bearer“传递。然而，在我看来，将这些令牌用于RESTful服务将违背REST所包含的真正的无状态含义；因为这些令牌是在服务器端创建/维护的临时数据片段，用于在web客户端/服务器对话的有效持续时间内识别特定的web客户端用户代理。因此，如果我们想坚持无状态协议的真正含义，任何使用这些OAuth1/2令牌的服务都不应该被称为REST。

鲁本斯