访问/刷新令牌管理的想法

Question

我有一个 Web API，它使用 JWT 令牌来访问资源。身份验证成功后，将生成令牌并将其发送到客户端。客户端通过使用特定标头（Bearer）附加每个请求来使用它们来访问 API 资源。有点标准的做法。

但就我而言，还需要在退出/关闭应用程序后立即“忘记”令牌（特定的安全措施）。

其中一个问题是客户端（在我的例子中是一个网络应用程序）如何存储令牌。基本上有两种选择：

1. http-only

   ，

   session

   关闭窗口时立即过期的cookie；
2. 会话存储。

(1) 的问题是，当浏览器选项卡关闭时，它不会被清除，只有当所有窗口都关闭时，它才会被清除。 (2) 并不安全，因为如果攻击者设法将代码注入客户端，他将能够提取访问令牌。

作为一种解决方法，有些人倾向于最小化访问令牌的生命周期并使用刷新令牌。除此之外，创建刷新令牌重用检测和其他内容。

另一种可能的解决方案是使用一个特定的 BFF，它代表客户端通过 API 进行身份验证（在这种情况下就像代理一样），存储攻击者无法访问的访问令牌，并为客户端提供一个包含另一个 cookie 的 cookie。 “令牌”。但这并不能解决所需的选项卡关闭问题，而且还增加了更多的复杂性和另一个需要支持的项目（更不用说延迟了）。

但我想到了两种方法的结合。

该令牌是一种 JWT 类型，由

header

、

payload

和

signature

组成。如果 API 将此令牌分为两部分：

header

+

payload

用于

http-only

、

session

cookie 和

signature

用于客户端包含在标头中，会怎样？

然后，客户端将照常发送包含“令牌”的请求，并使用 cookie 和 JWT 的其余部分。服务器收到请求后只会连接两个部分并使用它。

这解决了两种情况：

1. 令牌的相关部分安全地存储在

   http-only

    cookie 中，JS 无法访问（即安全）；

2. 关闭选项卡时签名将会丢失，因此 cookie 将无法使用（即关闭选项卡时“忘记”令牌）。

大家对此有何看法？这是一个可用的模式吗？以前有人用过这样的东西吗？也许这种方法存在一些问题？

当然，这可以与刷新令牌和其他一些模式一起使用。

Answer 1

requirement

很有趣，因为它不利于可用性。例如，用户希望能够进行多选项卡浏览，因此可能会发现所提议的行为令人困惑。作为默认位置，我会在 cookie 中采用短期访问令牌，这些令牌在浏览器选项卡关闭后会过期 

soon

。

您的建议很有趣，并且存在这种类型的有效解决方案。我在 Curity 工作，

我们关于分割令牌模式的文章

是一种可能的相关 API 接收令牌方法。

设计解决方案

您的建议有一定的有效性，但安全性往往是与其他因素的权衡，并且存在以下缺点：

非标准 API 客户端安全性，使用多个 HTTP 标头，更复杂且更难以解释。
适用于默认的多选项卡浏览功能，这还要求签名部分存储在本地存储中，而不是会话存储中。
非标准 API 安全性，尽管防止这种情况的一种选择是使用 API 网关在需要时重构 JWT 访问令牌，然后再将其转发到 API。这样做将使非浏览器客户端能够以标准方式调用 API。
有时利益相关者会通过笼统的声明提出这种类型的

requirement

。这可能会导致意想不到的成本，因此如果适用的话，也许可以在最终确定设计之前与他们讨论我提出的利弊。