使用REST API进行适当的会话管理

Question

我已经完成了RESTful API的设计,其中我使用作为参数发送的API令牌对每个请求进行身份验证.
现在我想创建一个客户端界面,我想知道什么是一种管理每个浏览器客户端会话的正确安全方式.

我考虑过保持服务器端无状态的流程:

• Web客户端使用用户和密码登录
• 服务器响应使用用户的API令牌
• 客户端将令牌存储为cookie
• 客户端将令牌作为参数发送给每个请求,如API服务器所期望的那样

但是这里的某些东西对我来说似乎不对...这不是太脆弱吗？
我们假设我正在使用SSL,但仍然
不能轻易地以这种方式窃取API令牌吗？
它甚至是一种正常的工作方式吗？

Answer 1

将您的令牌存储在用于Web应用程序的cookie中,因为它们提供了额外的安全性,以及使用现代Web框架防止CSRF的简单性.HTML5 Web存储容易受到XSS攻击,具有更大的攻击面积,并且可以在成功攻击时影响所有应用程序用户.

请参考以下链接:

https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

Answer 2

在适当的 REST 中，您不能进行会话。因为它们往往存储在服务器上。

因此，您需要为每个请求重新标识用户。

您目前拥有的是 OAuth 方法。您发出一个令牌，当提供时，该令牌将被视为身份证明。如果有人设法窃取该令牌，则没有简单的方法可以检测到它。至于“怎么可能被盗”，主要的载体是XSS、浏览器扩展和物理访问。你可以减轻 XSS，但你真的不能对后两者做任何事情。

正如@Saikrishna Radarapu提到的那样，还有 CSRF 作为向量，但是，如果您将令牌存储在某个地方，那不是 cookie，这并不是真正的问题。

所以......潜在的选择。

最简单的方法就是为您的身份验证令牌添加过期时间。当令牌过期时，您要求用户重新登录。通过这种方式，成功的攻击将导致... emm .. 机会窗口，您可以在执行破坏性操作时通过要求用户重新输入密码来进一步限制。

另一种选择是基于这种方法为记住我的 cookie建模令牌，但是这种方法有一个严重的缺点——它在异步环境中不能很好地发挥作用。您可以通过为每个令牌应用“保险丝”来缓解它 - 在第一次使用时将其标记为“易失性”并为其分配几秒钟的“燃烧时间”。在那几秒钟内，继续返回相同的“新”令牌，然后将原始令牌标记为“已过期”。XX

我正在考虑的第三个选项是只使用 HTTP Basic Auth或Digest Auth，但我实际上从未在实践中尝试过这些。

所以......这是我在这个话题上的两分钱。