我有一个使用 WCF 实现的 REST 端点。所有来回的数据均使用 SSL 加密。我正在开发一个 Web 前端(仅使用纯 HTML 和 Javascript)来公开服务的功能。但是，我对如何处理身份验证有点困惑。
根据Fielding 5.1.3:“...从客户端到服务器的每个请求都必须包含理解该请求所需的所有信息，并且不能利用服务器上任何存储的上下文。因此 session 状态完全保留在客户端上。 ”
当然，我希望应用程序有一个登录页面，允许用户输入其凭据，然后 REST 服务将“验证”它们并确保它们有效。但是，如果我保持 REST 服务无状态，那么客户端的身份验证信息应该存储在哪里？我研究过 OAuth 1.0 和 2.0 草案等解决方案，但似乎这不是我需要的。
主要是，我的问题是，如果用户“身份验证成功”，我如何在客户端维持此状态？
这是数据流:
用户查看登录页面 ---> 浏览器向 REST 服务提交 AJAX 请求并等待回复 ---> 服务器返回有效---> REST 服务现已解锁，可供当前登录用户范围内的当前“ session ”使用。
最佳答案
我处于类似的情况并使用 OAuth 2.0。我有几个域，即一个用于管理帐户，一个用于开发人员，一个用于 API，一个用于应用程序。我允许其他第三方使用 REST API。使用 dotnetopenauth 4 相当简单。
REST 服务器本身不维护任何状态。任何 Web 应用程序都会从帐户网站请求“ token ”，而帐户网站又会使用 openid 2.0 对用户进行身份验证。每次调用都会验证 REST 服务器的“ token ”。状态由 Web 应用程序维护，因为 token 存储在数据库(用于持久性)和 session (用于缓存)中。这非常适合从其他应用程序中模拟用户，而无需向应用程序透露任何“ secret ”。该协议(protocol)处理 token 的到期和撤销。该应用程序充当浏览器请求(包括 AJAX)的代理。这在安全性方面简化了客户端的 JavaScript。
另一种方法是使用 Amazon 方式，使用 REST 服务拥有的 key 对请求进行签名。对于每个请求，您执行完全相同的算法来签署请求，如果相同，您就知道该请求是合法的。虽然这比 OAuth 2.0 更简单，但您需要发明自己的方案来处理被撤销的 secret 。
关于jquery - 保护休息端点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9589272/