在cookie中保存身份验证令牌(Django Rest Framework + React)

Question

所以,正如标题所说我使用的是Django Rest Framework,结合了React.

我使用令牌认证对用户进行身份验证 现在我遇到了一个问题.当我重新加载页面时(例如,通过按F5键),所有状态都消失了,在这种情况下我无法保存令牌,要求用户再次登录.

我想过将令牌存放在cookie中,但这似乎不太安全.

还有其他问题,但没有答案真正解释了这有多大的安全风险.我觉得它很高,因为拥有令牌似乎足以作为后端的某人进行身份验证.

所以,我的问题是:我的假设是,将我的身份验证令牌存储在cookie中是不是安全吗？

注意:我正在考虑切换到基于会话的身份验证,但我宁愿保护我的工作并保持令牌身份验证.

Answer 1

这也是我必须处理的事情.在此过程中失去了几个晚上的睡眠.

免责声明:我不是安全方面的专家.只是有点痴迷(读:偏执).

简短版本(回答你的问题):我最终使用window.localStorage来存储令牌.虽然我不相信自己这是最好的事情,但它不只是关于"存储"部分 - 阅读长版本以了解更多.

长版: 首先,让我们澄清一些事情.React更像是一个移动应用程序,而不是一个网页/网站.我不是在谈论React Native - 我的意思是React.js.

为什么我说它更像是移动应用而不是网站？传统网站通常使用基于会话的身份验证,通常为其准备浏览器/服务器.显然,这是一项毫无疑问的无缝任务.

在移动应用程序(或客户端独立应用程序)中,您需要维护某种令牌,基本上告诉服务器"嘿,这是我!我刚刚访问过.这是我的身份证.请允许我进来？" .问题是,很难在客户端保持令牌安全.在Android v4.3之前,Android本身并未提供任何存储身份验证令牌的安全方法.这也不够安全,所以他们不久前引入了硬件支持的密钥库.这就是为什么有些应用程序没有(现在仍然没有)使用root设备的原因.在此处阅读更多相关信息:https://stackoverflow.com/a/19669719/3341737

与React/standalone Web应用程序相比,Google(有点)控制Android客户端.他们实现基于硬件的密钥库比较容易.在Web应用程序的情况下,有大量的浏览器,有数百个版本和诸如此类的东西.

回到window.localStorage.与Cookie类似,localStorage针对每个域进行隔离.由于它是一个较新的API,它的设计比好的旧Cookie更好.

加密密钥没有意义(尽管你可能会对其进行模糊处理),因为你需要在本地某处存储解密密钥.因此,如果有人可以访问令牌,他们也可以访问解密密钥.

这个问题的第二个方面(以及为什么"存储"不是唯一的问题)是 - 你真的想从谁那里保护令牌？

1. 男人在中间？使用SSL.
2. 其他网站？他们无法访问您域名的localStorage.
3. 一些人？真正.如果他们可以物理访问PC,他们可以轻松获得令牌.物理访问实际上使它们成为用户(您想要保护令牌免受用户影响吗？).考虑到此人具有物理访问权限,即使您以某种方式安全地存储令牌,也无法保护令牌.

为什么不？因为您需要在每个请求中发送令牌 - 并且每个请求发送的数据都可以在浏览器网络检查器中找到.因此,无论您在何处以及如何存储令牌,都可以被物理访问PC的人窃取.

为什么不用Cookie？有两个原因(实际上是1个):

1. 默认情况下,Cookie随每个请求一起发送.你真的不需要这个,因为你只需要在API调用期间发送令牌(而不是页面加载).此外,由于您正在使用DRF(适用于任何RESTful API后端),您可能需要发送令牌是服务器的特定方式 - 这需要任何方式的自定义方法.
2. window.localStorage是一个可以使用的简洁API(只是I thought about storing the token in a cookie, but that doesn't seem very safe.).此外,与Cookie相比,最大尺寸限制要高得多.

因此,window.localStorage对我来说似乎是一个可行的选择.如果你有更好的解决方案,请启发我.

话虽这么说,但这并不意味着你无法提高安全性.以下是一些建议:

1. 在一段时间后或在一段时间不活动后,从DB中无效/删除令牌.
2. 使用足够随机的请求发送更新的令牌(也使前一个令牌无效),并用新的令牌替换存储的令牌.
3. 授予用户访问权限,以删除其帐户的已保存令牌以及每个令牌的上一个活动.
4. 如果您真的(真的)担心,请将令牌绑定到用户IP(或其他无法克隆到其他系统的内容).如果用户从新设备/位置/浏览器登录,请使用2FA.