在使用带有刷新令牌的访问令牌后，我遇到了两难
境地。假设我们有以下方案：
用户登录 -> 返回有效期为5 分钟的访问令牌并将其保存在本地存储中。同时，有效期为3 个月的刷新令牌保存在具有httpOnly和安全属性的cookie中。应用程序将使用访问令牌来获取对资源的访问权限，并在 5 分钟后过期，它将自动使用刷新令牌生成新的访问令牌。3 个月后，将要求用户再次登录。
用户登录 ->有效期为3 个月的访问令牌保存在具有httpOnly和安全属性的cookie中。应用程序将使用此令牌来获取对资源的访问权限，3 个月后将要求用户再次登录。
使用方法1而不是方法2有什么意义？
什么都没有。如果你能做到#2，那么你应该这样做，而且更安全。JWT 被严重过度使用，在 #2 的情况下，您的访问令牌几乎就像一个普通的旧会话 ID，那么为什么不只使用会话 ID？(唯一的原因可能是真正的无状态，但在许多情况下，应用程序无论如何都不是无状态的，例如，如果您希望能够撤销令牌。
您无法使用 #2 将访问令牌发送到不同的源，有时实际上是需要的。假设您的应用托管在 example.com 上，但您的 API exampleapi.com。如果将访问令牌存储在 Cookie 中，则无法将其发送到 API。在更通用的情况下，通常发生的情况是，您有一个刷新令牌(几乎类似于会话，但没有服务器端状态(，该令牌提供程序可以在 idp.example.com 上颁发令牌，这是安全的 htponly cookie 的域。这会发出一个 jwt，您的应用程序从 www.example.com 下载可以在 api.example.com 或其他任何地方使用，因为访问令牌由 javascript 存储(例如在 localStorage 中(。关键是令牌可以通过javascript(xss(访问，但它的生存期很短，并且xss需要用户交互，因此攻击者不执行任何操作即可颁发新的访问令牌。刷新令牌更安全地存储在 httponly cookie 中。
如果您不想将令牌发送到不同的来源，httponly cookie实际上更好，您是对的，刷新令牌没有多大意义。请注意，如果令牌存储在 cookie 中，您也必须减轻 csrf。