我必须将令牌存储在cookie、localstorage或session中吗？
我必须将令牌存储在cookie、localstorage或session中吗？
我正在使用React SPA，Express，Express-session，Passport和JWT。
我对客户端存储令牌的不同选项感到困惑：Cookies，Session和JWT / Passport。
即使我可以将令牌存储在req.sessionID中，令牌是否必须存储在cookies中？
许多网站使用cookies存储购物车令牌。到目前为止，我已根据会话ID存储购物车数据，而没有添加任何cookies。
因此，当用户访问我的网站时，我将与其
req.sessionID匹配，然后从数据库中检索数据，例如购物车和用户会话。
我需要存储cookies吗？我可以通过req.sessionID访问它以获取所需的数据。
其次
我使用passport-google-oauth20进行身份验证。成功登录后，数据将保存到会话中。要将其发送到客户端，我必须通过URL查询?token='sdsaxas'发送它。
在这种情况下，意见不一。有人将其保存在本地存储中，有人将其转换为JWT并将其保存到cookies中。
jwt.sign(
payload,
keys.jwt.secretOrPrivateKey,
{
expiresIn:keys.jwt.expiresIn // <我不知道这个cookies或localstorage过期是为了什么？
}, (err, token) => {
res.redirect(keys.origin.url + "?token=" + token);
});
我确实可以通过使用sessionID（而不是cookies或localstorage）存储与会话相关的所有内容吗？
只需进行一次或每次页面刷新时的一次fetch，并检索数据，然后将其保存到redux中，因为我使用React SPA。
HTTP是一个无状态的协议，这意味着HTTP服务器不会在一个请求之后存储任何关于客户端的信息。这对于Web应用程序来说是一个问题，因为这意味着无法记住哪个用户已登录。
为了解决这个问题，发明了Cookies。Cookies是客户端和服务器在每个请求中来回发送的文本数据。它们允许你通过让客户端和服务器在每次通信时都记住一些信息来有效地维护应用程序的状态数据。
这意味着，基本上，没有Cookie就无法使用会话。必须有一个Cookie来存储至少会话ID，这样你就可以通过查找会话来确定当前哪个用户已登录。这就是express-session的作用：主要的session方法的文档明确指出会话ID存储在一个Cookie中。
所以我的问题是，我需要存储Cookie吗？因为我可以通过req.sessionID访问所需的数据。
你不需要自己存储Cookie，express-session会为你处理这个。但是你的整个应用程序需要存储一个Cookie；如果没有它，你就没有一个req.sessionID可以查找。
在这种类型的应用程序中，不会管理服务器端会话。相反，会使用Cookie来存储身份验证令牌，而不是会话ID。服务器端会话在扩展方面比较困难，我们正在向基于微服务的架构转变。
express-session的文档明确表示它确实使用服务器端会话，只是将会话ID存储在一个Cookie中。
在开发中，我们经常需要存储用户的令牌（Access Token），以便在用户进行身份验证时使用。在存储令牌的过程中，有人会提出一个问题：“我必须将令牌存储在Cookies、LocalStorage还是SessionStorage中吗？”这个问题的出现是因为LocalStorage和SessionStorage容易受到跨站脚本攻击（XXS）的威胁，而Cookies相对更安全一些。
LocalStorage和SessionStorage容易受到XXS攻击，因为令牌可以被JavaScript读取和访问。而使用带有httpOnly、secure和SameSite=strict标志的Cookies更加安全，因为令牌及其有效负载无法被JavaScript访问。然而，如果存在XXS漏洞，攻击者仍然可以以经过身份验证的用户身份发送请求，因为恶意脚本无需读取Cookie值，浏览器会自动发送Cookie。
尽管上述说法是正确的，但风险是不同的。使用Cookies，令牌仍然是隐藏的，攻击者只能进行“站内”攻击。注入到Web应用程序中的恶意脚本可能受到限制，或者可能不太容易更改/注入更多脚本。攻击者可能需要首先针对用户或Web应用程序进行攻击。这些条件限制了攻击的规模。
而使用LocalStorage，攻击者可以读取访问令牌并进行远程攻击。他们甚至可以与其他攻击者共享令牌并造成更严重的损害。如果攻击者设法在内容分发网络（CDN）中注入恶意脚本，比如Google Fonts API，攻击者将能够从所有使用受到攻击的CDN的网站中窃取访问令牌和URL，并轻松找到新的目标。使用LocalStorage的网站更容易成为攻击目标。
为了论证这个问题，一些渗透测试可能会将您在LocalStorage中存储敏感数据的做法视为风险。如果JavaScript可以从XSS攻击中读取LocalStorage中的访问令牌，为什么大家还要推荐使用httpOnly标志呢？
根据OWASP的建议，不要将会话标识符存储在LocalStorage中，因为数据始终可以被JavaScript访问。使用httpOnly标志的Cookies可以减轻这种风险。
为了确保令牌的安全性，推荐使用带有httpOnly、secure和SameSite=strict标志的Cookies来存储令牌，而不是使用LocalStorage或SessionStorage。这样可以减少受到XXS攻击的风险，并降低被攻击的潜在规模。
这个问题的出现是因为在进行身份验证时需要存储令牌(access token)和刷新令牌(refresh token)，需要选择一个合适的存储方式。内容中提到了三种常见的存储方式：cookie、localStorage和sessionStorage。其中，cookie被认为是最安全的选项。
解决方法是使用cookie来存储令牌。这样可以确保令牌在每个HTTP请求中都会被发送到服务器，并且服务器可以通过验证数字签名来确保令牌的完整性和有效性。此外，使用cookie还可以防止跨站请求伪造(CSRF)攻击。
在使用cookie存储JWT时，还需要考虑CSRF攻击的风险。为了防止CSRF攻击，可以在每个AJAX请求中使用CSRF cookie，将cookie的值添加到自定义的HTTP头中。这样可以防止CSRF攻击利用POST、PUT和DELETE等不安全的HTTP方法。同时，使用HttpOnly和Secure属性的cookie可以防止XSS攻击读取cookie的值。
除了使用cookie，还可以使用其他的CSRF防护方法，比如使用状态变量、检查referer头、禁止TRACE HTTP方法以及设置Strict-Transport-Security头。
需要注意的是，尽管使用cookie来存储JWT是较为安全的方式，但仍然需要注意其他安全性问题，比如XSS攻击和跨站脚本注入。可以通过使用适当的content-security-policy响应头来进一步减轻这些安全风险。
为了安全存储JWT令牌，在进行身份验证时，建议使用cookie来存储令牌，并采取适当的安全措施来防止CSRF攻击和其他安全风险。