带有 React 和 Node 的 httpOnly cookie

Posted 2023-02-19

【中文标题】带有 React 和 Node 的 httpOnly cookie

【英文标题】：httpOnly cookies with React and Node

【发布时间】：2021-06-23 03:54:34

【问题描述】：

我正在尝试弄清楚如何使用 httpOnly cookie 和可扩展性可选性来使用 React 和 Node 实现身份验证/授权。我读过 JWT 可以通过使用刷新令牌和 httpOnly cookie 来解决这个问题。

对我来说，第一个问题是如何通过 react 使其以正确的方式工作，因为 httOnly cookie 无法通过 JS 访问。 第二件事是，我希望我的前端和后端存在于分离的 dockerized 容器中，但据我所知，httpOnly cookie 仅添加到同一域（和同一端口）的标头中。* 更新实际上，我刚刚读到这不是真的，我可以在同一主机上使用 httpOnly cookie，但端口不同。*Update2，我记得它是什么关于：cookie 上的“SameSite”属性。这会将 cookie 绑定到同一个源，这意味着端口差异将被视为不同的源，并且不会传输 cookie。

能否请您澄清一下，也许可以解释一下，它真的那么重要吗？我的意思是，如果我想使用一些超级超高度安全的网站，我真的会处于危险之中，但是，我会使用 JWT 和本地存储（但有刷新令牌）？ httpOnly(and sameSite: true) cookie 真的会在这里有所作为吗？

谢谢

【参考方案1】：

在我的项目（也是 Node + React）中，我做了以下事情：

对于每个经过身份验证的用户（用户名 + 密码），我签署了两个令牌，一个访问令牌和一个刷新令牌。 我使用httpOnly 属性在响应标头中设置了刷新令牌。请注意，除非您设置属性 Secure 和 SameSite，否则最新版本的浏览器将不允许第三方 cookie（来自不同域）。 我将访问令牌作为响应正文返回

现在在客户端（你的 React 应用）：

您将在响应正文中获得访问令牌，这里有两个选项。将其存储在local storage 或内存中。由于 XSS 漏洞，我选择将令牌保留在内存中。 （这显然需要您在每次页面刷新时获取另一个访问令牌，因为内存已被清除） 刷新令牌无法通过 JS 访问你是对的，但你不需要它。这个令牌将在每个请求上发送，通常它的到期日期应该很长（我设置为 6-12 个月） 每次你想获得一个新的访问令牌（因为它的到期时间应该是 一个小的，大约 15-20 分钟），您将向服务器发送请求以“刷新”您的访问令牌，服务器将检查请求标头中是否存在刷新令牌，如果不返回状态 @ 987654326@

编辑：jwt 令牌不是“安全”或“不安全”，它们只是包含一些数据的令牌，它们允许您使您的身份验证过程无状态（而不是管理服务器中的会话）。只要您不在其中存储任何敏感数据，并使用只有您拥有的密钥对其进行签名，就可以了

编辑 2：由于您使用的是“清理”DOM 的反应，XSS 的可能性很小，所以使用本地存储是可以的，很多网站都这样做。但是因为仍有可能（您或客户将脚本注入某个输入元素），所以我决定将访问令牌存储在内存中，这有点开销，但我更喜欢这样做。

【讨论】：

感谢您尝试提供帮助并分享您解决问题的方法，但是，由于许多原因，我认为这不是正确的方法...例如，是什么让您认为-内存比本地存储更安全？潜在的黑客可以像访问本地存储一样访问它......此外，长时间制作刷新令牌是没有意义的，你失去了制作它们的全部意义，因为它们存在确保常规令牌无效，但您可以通过实现另一个可能“丢失”的令牌来解决这个问题。废话。

本地存储更容易受到攻击，因为任何人都可以访问它 (window.localstorage)。将它存储在内存中的好处是访问通常存在于函数范围内的 js 变量的机会较小（尤其是在反应中）。关于刷新令牌策略，这就是您使用它们的方式。他们有这么长的时间来刷新您的访问令牌是有原因的。 6-12 个月的到期日期是可选的。如果您查看 Google OAuth2 服务，它们的刷新令牌永远不会过期。另一方面，访问令牌应该在短时间内有效，以防被盗。

这里有一个很好的video 说明如何使用刷新令牌进行身份验证