Web 应用程序的基于令牌的身份验证：如何缓存令牌？

Question

我正在尝试将 Web 应用程序从“传统”基于 cookie 的身份验证机制切换为纯粹基于令牌的身份验证机制。 客户端收到令牌后应进行缓存以减少开销。 存储令牌的最佳方式是什么？

这是我从谷歌搜索中学到的：

我研究的第一个有希望的途径是浏览器会话存储，但是，据我所知，即使跨选项卡也不会共享，这意味着如果用户使用新选项卡点击来自网站的链接，他们将不得不登录再进去。

还有本地存储，但我希望用户在关闭浏览器时自动退出，而且我对存储中的令牌也有点不安，即使我在服务器端使它们过期。 只是看起来不干净。

另一种方法是将令牌存储在会话 cookie 中，这意味着它会在浏览器关闭时被杀死，并且可以跨选项卡共享。 这几乎是理想的，除了 cookie 当然会在每次访问服务器时通过网络发送，如果可能，我想避免这种情况。 尽管这不是安全问题，但通过 cookie 以及 HTTP Authorization 标头发送它似乎是多余的。 我曾考虑将 cookie 路径设置为我的域中不存在的路径，但这也不完全是美的缩影......

因此，面对三个非最佳解决方案，我再次向 SO 寻求帮助。 你们是怎么做的？ 最好的方法是什么？

tl;dr 在单页 Web 应用程序中持久化身份验证令牌的规范方法是什么？

Answer 1

t;dr 我正在使用localStorage来存储令牌。

我正在使用localStorage在客户端存储令牌。 您可以在我的文章中查看我的实现细节： React Token Based Authentication to Django REST API Backend 。

localStorage跨选项卡共享令牌，并且在您关闭选项卡时不会消失。 localStorage的数据一直存在，直到被明确删除。 sessionStorage的数据在 session 结束时被删除。

网上有一些讨论， localStorage是不安全的，因为在XSS攻击的情况下，黑客可以从中读取所有数据。 这是真的。 有一些讨论认为 httpOnly cookie 更好地存储令牌，因为黑客无法从 httpOnly cookie 访问和读取令牌。 确实如此，但误解是 cookie 并不能阻止 XSS（即使您使用 httpOnly cookie 也可能发生 XSS）。 更重要的是，cookies 启用CSRF攻击。 而且，在 XSS 的情况下，黑客仍然可以对恶意请求使用 set httpOnly cookie（类似于 CSRF）。 所以这里没有明显的赢家。 最安全的方法是不在客户端存储令牌。