保护休息端点

Question

我有一个使用WCF实现的REST端点。来回的所有数据都使用SSL加密。我正在开发一个Web前端（仅使用纯HTML和Javascript）来公开服务的功能。但是，我对如何处理身份验证感到有些困惑。

根据Fielding 5.1.3：“......从客户端到服务器的每个请求必须包含理解请求所需的所有信息，并且不能利用服务器上任何存储的上下文。因此，会话状态完全保留在客户端上。“

当然，我希望有一个应用程序的登录页面，允许用户输入他们的凭据，然后REST服务将“验证”它们并确保它们有效。但是，如果我保持REST服务无状态，我在哪里将身份验证信息存储在客户端？我已经研究过诸如OAuth 1.0和2.0草案之类的解决方案，但似乎这不是我需要的。

主要是，我的问题是，如果用户“成功验证”，我如何在客户端维护此状态？

以下是数据流：

用户视图登录页面---＆gt;     浏览器向REST服务提交AJAX请求并等待回复---＆gt;             服务器返回有效---＆gt;                      现在，REST服务已解锁，可以用于当前登录用户范围内的当前“会话”。

Answer 1

当用户成功登录时，您应该生成一个身份验证令牌，并将其保存在用户的cookie中。该身份验证令牌在db中映射到用户的用户名。

对于用户发送到其余服务的每个请求，从cookie中获取该令牌并将其发送到标头或请求正文中。该服务将查找该令牌并将其与用户名进行匹配。

您可以使用The Microsoft Enterprise Library Security Application Block生成代币。

Answer 2

我看到的最简单的解决方案是将您的登录凭据放在加密的cookie中。我已经看到关于cookie是否可以成为RESTful服务的一部分的一些争论，我可以理解cookie不属于REST的论点，但这肯定是使用cookie的最RESTful方式。除了我可以看到的最简单的解决方案是，你可以通过每次调用传入（并且可能返回）某种登录哈希值。

Answer 3

我处于类似情况并使用OAuth 2.0。我有几个域，一个用于管理帐户，一个用于开发人员，一个用于API，一个用于应用程序。我允许其他第三方使用REST API。 dotnetopenauth 4是相当简单的。

REST服务器本身没有维护状态。任何Web应用程序都要求帐户网站提供“令牌”，然后使用openid 2.0对用户进行身份验证。每次调用都会验证REST服务器的“令牌”。状态由Web应用程序维护，因为令牌存储在数据库（用于持久性）和会话（用于高速缓存）中。这非常适合用户模仿其他应用程序，而无需向应用程序透露任何“秘密”。该协议处理令牌的到期和撤销。该应用程序充当浏览器请求的代理，包括AJAX。这样可以简化客户端上的javascript安全性。

另一种方法是使用Amazon方式，您可以使用REST服务具有的秘密对请求进行签名。对于每个请求，您执行完全相同的算法来签署请求，如果它是相同的，您知道请求是合法的。虽然这比OAuth 2.0简单，但您需要发明自己的方案来处理被撤销的秘密。