在我的后端，我检查了jwt到期之前剩下多长时间（15分钟）。如果是一分钟或更短的时间，我会创建一个新的，然后将其附加到Settoken标题中的响应中。然后，前面将存储并使用新的。这是一个好方法吗？关于此事的意见？
谢谢
您的想法很好。您正在实现令牌刷新算法。取决于用例，但最好更频繁地回馈新的新鲜令牌，不仅是在下一分钟即将到期时。
例如，一种常见的方法是将带有概率分布的新鲜令牌回馈（例如，每个请求的概率为30％，可以发送回新令牌）与像您这样的正时算法结合使用。因此，对于每个请求：
if (30% of times true || token is expiring in next n seconds)
give a new refresh token.
概率分布用于限制签名所需的CHE CPU使用。
另一种方法是实现只需验证提供的JWT的API（例如GET /token），如果它有效，则会生成新的新鲜JWT作为响应。通过这种方法，"何时刷新"逻辑移至客户端。客户应决定何时致电/token API以刷新他的令牌。通常，这是在Web应用程序/移动应用程序启动时完成的。或每n分钟，如果您将JWT用于服务器进行服务器交流。
我认为，第二种方法是首选。
从我的角度来看，这并不是一个好主意。问题不是安全性，而是逻辑上的安全性。
您将对资源的访问与发行代币混合在一起。如果客户需要一个令牌，则应明确要求新的端点并联系专用端点。如果令牌已过期，则您的服务器可能需要其他信息（刷新令牌，验证凭证材料...）。
随着您的流程，客户将收到尚未要求的令牌。此外，除了您的应用程序逻辑外，您的客户必须检查每个请求是否存在新令牌。如果旧的访问权限到期，它可能会错过新的访问令牌，并丢失访问权限。
终于但并非最不重要的一点是，这个新的令牌可能没有用，并且从未被客户使用。