哪个JWT刷新策略更安全？

Question

基本思想是用户会话应该很长，并且根据用户活动继续/禁用。然而，由于我们不能撤销令牌，所以令牌应该是短期的，比如15分钟。如果我们可以在令牌过期后刷新令牌，那么用户会话可以继续。

经过一些研究，我发现有两种实现：

一个用于刷新过期，一个用于令牌过期。刷新TTL比令牌到期TTL长。如果客户端发现当前令牌已过期但仍可以刷新，则将调用服务器刷新api。新令牌将有新的到期时间和刷新到期时间。如果两个TTL都已过期，则该令牌无效，用户需要再次进行身份验证。Pros*不需要额外的身份验证服务器。*令牌的数据可以修改，以便在特定情况下替换会话。Cons*无法撤销刷新令牌。

刷新令牌是长寿的，例如一周。访问令牌（这里可以使用JWT）是短期的，例如15分钟。客户机持有这两个令牌，每次发现访问令牌过期（可以从访问令牌的有效负载中读取），它都会使用刷新令牌向身份验证服务器请求一个新的访问令牌。

赞成的意见

• 刷新令牌存储在auth server中时可能会被吊销

缺点

• 需要额外的身份验证服务器

让我们假设在选项1中，令牌到期时间是15分钟，令牌到期和刷新到期之间的时间间隔也是15分钟。在选项2中，访问令牌到期时间为15分钟，刷新令牌到期时间为一周。

• 两个选项都可以很好地刷新令牌，用户体验相同

• 选项1：令牌仍然有效。最多30分钟后，令牌将失效

• 选项1：令牌在最多30分钟后失效

• 选项1：尝试访问刷新API，使令牌保持刷新和可用

• 选项1：尝试访问刷新API，使令牌保持刷新和可用

我的问题是，选项2比选项1更安全吗？

我们的产品目前正在使用Distribution session来存储用户信息。我们希望消除对身份验证服务器和会话的使用，但安全是我们的首要任务。我没有看到选项2有多少好处。

我是误解了什么还是错过了什么更好的代币控制策略？任何建议都将不胜感激。

Answer 1

拥有刷新令牌的唯一目的是允许用户会话被更新，而无需用户再次输入密码。

让我们分成几个用例

考虑在银行网站、支付网站或公共云中的会话（AWS管理令牌可以删除所有公司的下一个）。

• 非常敏感的信息

对于这个用例，在没有再次进行用户身份验证的情况下，会话不能被扩展，因此刷新令牌是没有意义的。交付短期访问令牌，而根本不交付刷新令牌（可以在OIDC提供程序中禁用它们）。

考虑一个移动应用程序中的会话，可以是一个游戏，可以是一个应用程序（脸谱网）。

• 没有敏感信息（人们可能认为他们的facebook很敏感，但它一点也不像gmail或银行）
• 会话可能会持续一段时间。（你曾经在facebook或tinder上再次验证过吗？）
• 在手机上（重新）输入密码是一个巨大的PITA。（一定比例的用户在必要时不会回来。他们经常不记得或者不想要麻烦）。
• 手机是相对安全的。即使被盗，小偷通常也不能解锁屏幕或访问设备/应用程序的存储。

对于这个用例，拥有可以持续很长时间的会话是很好的，但是能够取消它们（设备丢失或被盗）是很重要的。交付访问代币一天，交付刷新代币三个月。

当应用程序打开时，它可以使用刷新令牌请求新会话，然后使用它。可以通过使刷新令牌无效来撤销设备访问（例如，请参阅facebook/gmail中的“我的活动设备”）。

唯一的一个小缺点是，如果应用程序几个月没有使用，用户必须再次进行身份验证，这在我看来是合理的。（市场营销/增长部门的观点可能会有所不同，他们可能会要求延长期限——无限期如何？——最好不要延长一年）。

我在这里主要关注移动应用程序，但网站在某种程度上可能类似。不同之处在于，笔记本电脑/台式机上的（浏览器）cookie极易提取，尽管最终用户有大量恶意软件/广告软件可能会将其抽走。因此，环境不太可信，这是存储长寿命代币的一个问题。

• TODO:明天再加上这个。到目前为止，我已经花了半个多小时来写了