如果用户仍在向系统API /服务器发出请求，如何确保用户访问令牌不会过期？
是否可以根据用户对服务器的每个请求刷新JWT到期日期？
答案 0 :(得分：0)
OAuth2 使用包含用户数据的短期访问令牌和用于询问的长期 refresh令牌以获得新的访问令牌。
只需指出，您只能在服务器端更改 JWT 的数据（或更准确地说，是创建新的）。即使可以公开访问其数据，其签名也基于其内容。因此，如果修改了其内容，则必须使用私钥再次对其进行签名，否则它将无效。 其目的不是隐藏数据（对于JWE / JWS而言除外），而是确保与其他客户端请求一起接收数据的服务器是真实的（由服务器创建，这要归功于其私钥，或者由服务器创建）。第三方身份验证服务）。 （对不起，如果您已经知道了）
如果您要实现一些特定且有限的安全性，并且想要简单一些，则可以在服务器端保留一些有关令牌到期的信息（例如，在数据库表中），然后发送新的信息以及响应如果您检测到它即将过期（并且 Authorization 标头的令牌正确）。
否则，您可以实施一些客户端轮询，定期询问新令牌（或者更好，但更复杂的服务器推送）。
我还研究了一个实现失败并重试的解决方案：如果服务器拒绝了令牌（5分钟后），则客户端与auth服务（具有提供的令牌的注册表）进行了联系。到期时间更长），从而提供了一个新令牌。之后，客户端重试了请求。
我还研究了一个实现，如您建议的那样，每个响应都发送了新的令牌。我们还将令牌列表保存在注册表中，以确保对于收到的令牌仅发送一个新令牌（以确保该系统不会乘以授权令牌）。在接收时，先前的令牌被禁用（但有宽限期：它们仍然有效一分钟，以确保并行调用能够到达服务器），同时提供新的令牌。该系统还确保了同一用户不能同时在不同设备上使用该应用程序（令牌是按用户划分范围的，删除了以前的用户令牌）。 只需注意，使用这样的系统，开发，调试，重播请求就变得很痛苦...
不是安全专家，我不能保证我的回答是防弹的。也许您很快就会收到更好的评论。
有一些常见的安全模式，例如OAuth，可以在其中找到有关OWASP的信息，安全专家的圣经，以及对您有用的第三方解决方案，例如Auth0（具有看看他们的关节，他们就是金矿。但是，软件/安全架构师绝对不会错过设计自己的自定义安全实现的机会（...并重新发明轮子）。