将JWT令牌存储在Non HttpOnly Cookie中，以结合指纹与多选项卡支持

Question

我阅读了关于在https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html上保护基于JWT的服务的信息。在本指南中，它告诉我们如何在客户端处理JWT令牌

由浏览器自动发送（Cookie存储）。

1. 即使重新启动浏览器也已检索（使用浏览器 localStorage容器）。
2. 在XSS问题（Cookie可以通过JavaScript代码或存储在浏览器本地/会话存储中的令牌访问Cookie）中检索。

如何预防

1. 使用浏览器sessionStorage容器存储令牌。添加
   调用时作为带有JavaScript的Bearer HTTP Authentication标头 服务。

2. 将指纹信息添加到令牌。通过存储 浏览器sessionStorage容器中的令牌，它将令牌公开给
   通过XSS攻击被盗。但是，指纹已添加到
   令牌可防止攻击者在其令牌上重复使用被盗令牌 机。为
   关闭最多的开采表面 攻击者，添加浏览器内容安全策略以强化
   执行上下文。

OWASP提供的解决方案限制

问题是，如果用户在同一浏览器的另一个选项卡中输入相同的URL，则不应向他显示登录页面，而应将其定向到主屏幕而无需任何登录过程。解决这个问题。我遵循以下方法。顺便说一句，我正在使用刷新令牌来支持滑动会话

1. 用户输入登录用户名和密码
2. 验证登录凭据后，将存储访问令牌 在非httponly安全的相同站点Cookie中，刷新令牌为 存储在安全的相同站点的httponly cookie
3. 通过不同用户的组合添加指纹值 嵌入令牌信息的上下文。这个指纹曲奇 值也存储在安全的相同站点，httponly cookie中，并且它 对提供给客户端的每个新访问令牌的更改。
4. “指纹”值用于防止令牌侧劫持。即使 访问令牌从cookie中被窃取。攻击者不会 由于缺少指纹信息，因此可以使用它
5. 在每个请求上，浏览器客户端将需要发送访问权限 通过获取访问令牌将令牌作为头中的承载令牌 存在于cookie中。这既充当CSRF预防机制，又充当用户身份验证机制。
6. 如果令牌过期，浏览器将调用刷新令牌URL 并且由于刷新令牌cookie已经存在，因此服务器 将自动获取刷新令牌并提供新的访问令牌 并刷新令牌。然后第二步再次发生

那么，这种方法安全可靠吗？由于适用了针对令牌劫持的对策。我应该担心将访问令牌存储在非httponly cookie中吗？

注意：之所以我不在内存中的JavaScript变量中同时存储访问令牌和刷新令牌，是因为这些令牌需要在同一域中托管的多个应用程序之间共享。