保护其余端点

Question

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

根据Fielding 5.1.3：“...这样每个来自客户端的请求都必须包含理解请求所需的全部信息，并且不能利用服务器上存储的任何上下文。因此完全依靠客户。“

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

主要是，我的问题是，如果用户“认证成功”，我怎么能保持这种状态在客户端？

下面是数据流：

用户查看登录页面---> 浏览器提交AJAX请求休息服务和回复等待---> 服务器返回有效---> 的REST服务现在已解锁并准备用于当前登录的用户范围内的当前“会话”。

Answer 1

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

REST服务器本身没有维护状态。任何Web应用程序都会从​​帐户网站请求“令牌”，然后使用openid 2.0对用户进行身份验证。每个呼叫都会验证REST服务器的“令牌”。状态由Web应用程序维护，因为令牌存储在数据库（持久性）和会话（用于高速缓存）中。这非常适合从其他应用程序中冒充用户，而不必向应用程序泄露任何“秘密”。该协议处理令牌的到期和撤销。该应用程序充当浏览器请求的代理，包括AJAX。这在安全性方面简化了客户端上的JavaScript。

另一种方法是使用亚马逊方式在其中使用REST服务所具有的秘密签署请求。对于每个请求，您执行完全相同的算法来签署请求，如果相同，则您知道该请求是合法的。虽然这比OAuth 2.0更简单，但您需要制定自己的方案来处理被撤销的秘密。

Answer 2

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

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

您可以使用The Microsoft Enterprise Library Security Application Block来生成令牌。

Answer 3

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