访问令牌和刷新令牌Dilema-JWT

Question

将访问令牌与刷新令牌结合使用后，我陷入了困境。

假设我们有以下几种情况：

1. 用户登录->返回有效期限为 5分钟的访问令牌，并将其保存在本地存储中。同时，有效期为 3个月的刷新令牌通过 httpOnly 和保存在 cookies 中安全属性。该应用程序将使用访问令牌来获取对资源的访问权，并且在到期5分钟后，它将自动使用刷新令牌来生成新的访问令牌。 3个月后，将要求用户再次登录。

2. 用户登录->有效期为 3个月的访问令牌通过 httpOnly 保存在 cookies 中>和安全属性。该应用程序将使用此令牌来访问资源，并在3个月后要求用户再次登录。

使用方法 1 代替方法 2 有什么意义？

Answer 1

什么都没有。如果您可以执行＃2，则应该这样做，这样更加安全。 JWT大量使用，在＃2的情况下，您的访问令牌几乎就像一个普通的旧会话ID，那么为什么不只使用会话ID呢？ （唯一的原因可能是真正的无状态，但是在许多情况下，应用程序仍然不是无状态的，例如，如果您希望能够撤消令牌。）

您无法使用＃2将访问令牌发送到其他来源，有时确实需要这样做。假设您的应用托管在example.com上，但您的api是exampleapi.com。如果您将访问令牌存储在cookie中，则无法将其发送到api。在更一般的情况下，通常发生的情况是，您拥有身份提供者的刷新令牌（几乎类似于会话，但没有服务器端状态），可以在idp.example.com上发行令牌，这就是安全的域曲奇饼。这会发出一个jwt，您的应用从www.example.com下载的jwt可以在api.example.com或其他任何地方使用，因为访问令牌是由javascript存储的（例如，在localStorage中）。关键是令牌可以通过javascript（xss）进行访问，但是它是短暂的，并且xss需要用户交互，因此攻击者在没有用户执行任何操作的情况下发布新的访问令牌并不容易。刷新令牌更安全地存储在httponly cookie中。

如果您不想将令牌发送到其他来源，那么httponly cookie实际上会更好，而且您说得对，那么刷新令牌就没有多大意义了。但是请注意，如果令牌存储在cookie中，那么您也必须减轻csrf的负担。