我在我的本地应用程序中使用JSON Web令牌进行身份验证。当用户登录时，将创建令牌并将其发送给用户以存储在本地存储中。令牌有效期为24小时。每当调用服务器（nodejs）时，令牌就会在标头中发送。
问题是24小时后，用户必须再次登录。我不想要这个，所以我开始寻找解决方案。我找到的解决方案：刷新令牌。
到目前为止，我的方法。如果我做错了事，请纠正我。
1）用户登录。身份验证令牌和刷新令牌都发送给用户以存储在本地存储中。 （这样够安全吗？）
2）用户想要更改其个人资料。我向标头中带有 auth令牌的服务器发送了请求。
3）服务器收到认证令牌。如果auth令牌仍然有效，请执行所有操作。如果auth令牌已过期，请检查用户是否具有刷新令牌（该令牌仍然有效）。在这一点上，我被困住了。我是否应该从服务器向用户发送新请求，并询问“您是否有刷新令牌？”如果可以，则将此刷新令牌发送到服务器以创建新的身份验证令牌？
我的问题如下：
比方说，用户希望从列表中获取最后10条消息。带有 auth令牌的请求将发送到服务器。
=>身份验证令牌为有效：响应是10条消息的列表
=>身份验证令牌为无效：响应是服务器向客户端提出的刷新令牌的新请求
这些是2个不同的响应。那不会在客户端弄乱我的代码吗？我该如何处理？
另一种选择是在每个请求中发送 auth令牌和刷新令牌。但这有道理吗？
答案 0 :(得分：0)
您是说像OAuth2中那样刷新令牌吗？如果是这样，它们通常仅用于服务器客户端（而不是浏览器应用程序）。使用刷新令牌需要客户端身份验证才能检索新的访问令牌，这使其与仅将访问令牌发送到资源（通常仅提供访问权限）不同。
因此，尚不清楚使用刷新令牌会在此处添加任何内容。如果您认为将人们登录到您的应用程序超过24小时足够安全，为什么不只是延长会话持续时间并延长您发行的令牌的使用寿命？
对于存储，将安全信息保存在本地存储中是generally frowned on。如果您确定自己没有易受攻击的外部Java脚本，并且在网站上使用了非常严格的Content Security Policy标头来防止任何内联Java脚本或不希望的源，并且您的应用程序风险不是很高，则可能是好吧。