问REST API登录模式

EN

Principled Design of the Modern Web Architecture by Roy T. Fielding and Richard N. Taylor，即来自所有REST术语的工作序列，包含客户端-服务器交互的定义：

所有的REST交互都是无状态。也就是说，每个请求都包含连接器理解该请求所需的所有信息，独立于它之前的任何请求。

此限制实现了四个功能，在此特定情况下，第一个和第三个功能非常重要：

• for : it 消除了连接器在请求之间保留应用程序状态的任何需要，从而减少了物理资源的消耗并提高了scalability;
• 3rd:它允许中介在中查看和理解请求，这在服务动态重新排列时可能是必需的；

现在让我们回到你的安全案例。每个请求都应该包含所有必需的信息，授权/身份验证也不例外。如何做到这一点？从字面上看，每个请求都会通过网络发送所有需要的信息。

如何理解这一点的一个例子是 or 。实际上，这意味着向每个请求添加当前消息的哈希码。由加密散列函数与秘密加密密钥组合计算的散列码。加密散列函数可以是预定义的，也可以是按需编码REST概念的一部分(例如JavaScript)。服务器应将秘密密钥作为资源提供给客户端，客户端使用该密钥计算每个请求的哈希码。

HMAC实现有很多示例，但我希望您关注以下三个示例：

• Authenticating REST Requests for Amazon Simple Storage Service (Amazon S3)
• Answer by Mauriceless on quiestion: "How to implement HMAC Authentication in a RESTful WCF API"
• crypto-js: JavaScript implementations of standard and secure cryptographic algorithms

它在实践中是如何工作的

如果客户端知道密钥，那么它就可以使用资源进行操作了。否则，他将被临时重定向(状态代码307临时重定向)以授权并获取密钥，然后重定向回原始资源。在这种情况下，不需要事先知道(即在某个地方硬编码)授权客户端的URL是什么，并且可以随时间调整此模式。

希望这能帮助你找到合适的解决方案！

实现安全性所必需的组件不是每个请求的DR登录，而是身份验证。

要回答你关于登录的问题很难不从总体上讲安全性。对于某些身份验证方案，没有传统的登录。

REST没有规定任何安全规则，但实际上最常见的实现是带3向身份验证的OAuth (正如您在问题中提到的)。没有登录本身，至少每个API请求都没有登录。对于3-way auth，您只需使用令牌。

1. 用户批准应用编程接口客户端，并授予以长期令牌的形式进行请求的权限。
2. API客户端通过使用长期令牌来获取短期令牌。
3. Api客户端随每个请求一起发送短期令牌。

此方案为用户提供了随时撤销访问权限的选项。实际上，我见过的所有公开可用的RESTful API都使用OAuth来实现这一点。

我只是不认为你应该把你的问题(和问题)框定在登录上，而应该从总体上考虑保护API。

有关REST API身份验证的一般信息，您可以查看以下资源：

• http://www.infoq.com/news/2010/01/rest-api-authentication-schemes
• REST API Authentication
• RESTful API Authentication

REST哲学的很大一部分是在设计API时尽可能多地利用HTTP协议的标准特性。将这一理念应用于身份验证，客户机和服务器将利用API中的标准HTTP身份验证功能。

登录屏幕对于人类用户用例非常有用:访问登录屏幕，提供用户/密码，设置cookie，客户端在将来的所有请求中提供该cookie。不能期望使用web浏览器的用户在每个单独的HTTP请求中都提供用户id和密码。

但是对于REST API来说，登录屏幕和会话cookie并不是绝对必要的，因为每个请求都可以包括凭证，而不会影响人类用户；如果客户端在任何时候都不合作，就会给出一个401 "unauthorized“响应。RFC 2617描述了超文本传输协议中的身份验证支持。

TLS (HTTPS)也是一种选择，它允许在每个请求中通过验证另一方的公钥来进行客户端到服务器的身份验证(反之亦然)。此外，这还可以确保通道的安全，从而获得奖励。当然，要做到这一点，在通信之前进行密钥对交换是必要的。(请注意，这具体是关于使用TLS来识别/验证用户。使用TLS / Diffie-Hellman保护通道始终是一个好主意，即使您不能通过用户的公钥来标识用户。)

例如:假设OAuth令牌是您的完整登录凭据。一旦客户端获得了HTTP令牌，它就可以作为每个请求的标准OAuth身份验证中的用户id来提供。服务器可以在第一次使用时验证令牌，并缓存带有生存时间的检查结果，该生存时间随每次请求而更新。任何需要身份验证的请求都会返回401 (如果未提供)。