短期和持久身份验证的登录/注册系统安全性工作流程

Question

我知道这个问题已经被打死了，因为我已经阅读了很多有关Cookie和会话以及JWT的文章，问题和想法。希望这个问题不会及时解决，以获取有关我如何处理该问题的反馈。

我选择的文章是

Charles Miller's article, "Persistent Login Cookie Best Practice,"

"Remember Me" - Long-Term Persistent Authentication

Getting Token Authentication Right in a Stateless Single Page Application

这是我的想法：

• 未登录的用户访问网站，创建了基本会话。

  • 跟踪用户互动（例如：将感兴趣的项目添加到购物车）。

• 未登录的用户登录或注册。

  • 如果存在会话，请根据需要传输会话数据。
  如第2条所述，创建
  • “ selector：validator”，将选择器放入JWT有效负载中，将验证器放入JWT标头中。 “ selector：validator”已保存在数据库中。
  • “持久”值以0或1的形式添加到标头中。
  • 如果选中“记住我”，则JWT过期设置将长期存在；如果未选中，则JWT需要15分钟。
  • JWT已按照3中的条款进行了签名并分为两部分：标头和签名作为长期安全的仅HTTP cookie发送，有效载荷作为可读cookie发送，有效期极短。

选择器和验证器的作用应类似于文章1中的系列标识符和令牌。

由于这不是SPA，并且我没有使用Angular，因此我想解决身份验证Bearer标头的问题是，只要页面加载，就在其过期之前获取可读的cookie。在随后的页面导航中，拦截锚点单击，使用可读cookie中的内容设置cookie，然后继续进行导航。据我了解，防止CSRF的一种主要方法是设置Bearer标头客户端，因此通过Javascript设置cookie会是相同的策略吗？

• 服务器上的安全页面请求，JWT重建并检查是否过期。
  • 如果已过期并且'persistent'= 0，则重定向登录。
  • 如果已过期并且'persistent'= 1，请针对DB进行检查selector：validator。
  • 如果选择器和验证器相同，则使用新的验证器发布和更新数据库，并签署新的JWT。
  • 如果只有选择器相同，则表示另一方使用了cookie，并且该方收到了新的验证器。完全使该选择器无效，然后重定向到登录。
  • 如果没有匹配项，请重定向到登录名。

我知道这不能解决XSS，但是如果XSS是该网站的主要问题，那么其他所有内容都将消失。

此工作流程有什么问题？一些改善的方法？还是完全删除以替代另一种选择？我知道这是一个非常广泛而笼统的问题，但我感谢您提供任何反馈意见，因此我可以避免再为这个问题而烦恼，而可以继续开发该网站。谢谢。

编辑：使用JWT的原因是该站点有些无状态...不需要在每个页面请求中都进行数据库查找。当JWT到期时，无论是否持续登录，查找仅每15分钟发生一次。我猜想使用常规的cookie并将验证器，userId和15分钟的过期时间放到一个长久的，安全的仅HTTP的cookie中就可以了，而无需JWT ...