背景
我正在基于JWT和Refresh令牌实现身份验证系统，但是我很难寻找有关刷新令牌生成和处理的详细文档。
我发现的常见情况是预期的：
- 无状态且未存储在服务器端的短期令牌JWT
- 一种长寿命的刷新令牌，该令牌存储在客户端和服务器端的某个位置，并允许获取新的授权JWT。
刷新令牌生成
我的第一个问题是关于刷新令牌的生成。我已经看到了两种主要情况：
- 刷新令牌是一个简单的随机字符串或一个uuid，它存储在服务器端（及其到期时间），代表长时间的用户会话
- 刷新令牌本身就是一个JWT，其中包含已登录并具有过期时间的用户的不敏感数据
第一种情况最简单，但只允许手动封装会话数据，第二种情况更复杂，但可以封装会话数据，到期时间，并且仅由服务器中保存的秘密生成（这意味着更多安全）。但是，在最后一种情况下，使JWT持久化与JWT的方法背道而驰，还需要更多的精力来验证JWT和比较数据。
刷新令牌工作流程
先决条件
在客户端存储刷新令牌是将会话持久保存在诸如浏览器之类的唯一方法。但是，它必须安全地存储，因此即使在这里也有两种情况：
- 刷新令牌存储在浏览器中，例如localStorage或sessionStorage（不太安全）
- 刷新令牌是使用HttpOnly cookie传递给客户端的，而Javascript无法访问。
问题
假设我们将刷新令牌存储在HttpOnly cookie中，我想知道：返回新的JWT和新的刷新令牌的端点/refresh_token是否需要授权？
- 如果必须对端点进行授权，则应该有一个有效的JWT来验证我的用户，而无需再次请求用户名和密码。如果用户在浏览器中使用Web应用程序，然后将其关闭，然后过一会儿他返回Web应用程序（并且JWT已过期），则这是不可能的，并且要求用户再次进行身份验证。
- 如果未授权端点，则在验证刷新令牌时，我将没有有效的用户实例来检查刷新令牌数据。因此，我唯一可以检查的是商店（或JWT策略）的刷新令牌的有效性。这可以解决上述情况，但是这样安全吗？
- 另一种情况是端点也接受过期的JWT，对其进行验证，然后检查刷新令牌。
应如何验证刷新令牌以实现安全实施？最佳做法是什么？