基本思想是，用户会话应该很长，并且应根据用户活动来继续/禁用。但是，由于我们无法撤消令牌，因此令牌应该是短期的，例如15分钟。如果我们可以在令牌过期后刷新令牌，则可以继续进行用户会话。
经过一些研究，我发现有两种实现此目的的方法：
一个用于刷新到期，一个用于令牌到期。刷新TTL比令牌到期TTL长。如果客户端发现当前令牌已过期但仍可以刷新，则客户端将调用服务器刷新API。新令牌将具有新的到期时间和刷新到期时间。如果两个TTL都到期，则该令牌无效，并且要求用户再次进行身份验证。优点*不需要其他身份验证服务器。*令牌的数据可以修改，以便在特定情况下可以替换会话。缺点*无法撤销刷新令牌。
例如，刷新令牌的寿命很长，例如一周。访问令牌（此处可以使用JWT）是短暂的，例如15分钟。客户端每次持有两个令牌时，都会发现访问令牌过期（可以从访问令牌的有效负载中读取），它将与刷新令牌一起进入身份验证服务器，要求新的访问令牌。
Pros
缺点
假设在选项1中，令牌到期时间为15分钟，令牌到期和刷新到期之间的时间间隔也为15分钟。在选项2中，访问令牌到期时间为15分钟，刷新令牌到期为一周。
我的问题是，选项2比选项1更安全吗？
我们的产品当前仅使用分发会话来存储用户信息。我们希望消除对身份验证服务器和会话的使用，但是安全是我们的首要任务。选项2没有太多优势。
我误解了某些东西还是错过了更好的令牌控制策略？任何建议将不胜感激。
具有刷新令牌的唯一点是允许更新用户会话，而无需让用户再次输入密码。
让我们分解几个用例
考虑在银行网站，支付网站或公共云中的会话（AWS管理员令牌可以删除下面的所有公司）。>>
对于此用例，必须在没有用户再次认证的情况下扩展会话，因此刷新令牌没有意义。提供短期访问令牌，根本不提供刷新令牌（可以在OIDC提供程序中将其禁用）。
考虑在移动应用程序中的会话，可以是游戏，也可以是应用程序（facebook）。
在此用例中，会话可以存活很长时间会很好，但是重要的是能够取消它们（设备丢失或被盗）。交付一天的访问令牌，并交付3个月的刷新令牌。
打开应用程序后，它可以请求带有刷新令牌的新会话，然后使用它。可以通过使刷新令牌无效来撤消设备访问权限（例如，参见facebook / gmail中的“我的活动设备”）。
[只有很小的缺点是，如果几个月没有使用该应用程序，则用户必须再次进行身份验证，这在我看来是合理的。 （市场营销/增长部门的观点可能有所不同，他们可能会要求将其延长-无限吗？-
。最好不要使其延长一年以上。]我在这里关注移动应用程序，但是网站在某种程度上可以相似。区别在于，尽管最终用户有大量的恶意软件/广告可能会把它们吸引出去，但笔记本电脑/台式机上的（浏览器）Cookie非常容易提取。因此环境不太值得信赖，这是存储长期令牌的关注点。