Light-OAuth2刷新令牌永生?(必须明确删除)



我有一个关于light-oauth2刷新令牌的问题。它们似乎永远不会过期,因此必须手动撤销,这导致了维护和安全问题,也似乎与轻型Auth2文件相矛盾。

(注意:我对这种行为的解释持开放态度,因为背后可能有很好的原因。这(目前)对我来说根本违反直觉。)

更多详细信息

刷新令牌在refresh_token表中无限累积。CacheStartupHookProvider中似乎没有任何代码为其提供TTL。正如你所看到的,似乎在1天后驱逐刷新令牌的代码已经被注释掉了(第108-119行):

// fresh token map with near cache and evict. A new refresh token will
// be generated each time refresh token is used. This token only lives
// for 1 day and it will be removed from the cache automatically.
MapConfig tokenConfig = new MapConfig();
tokenConfig.setName("tokens");
NearCacheConfig tokenCacheConfig = new NearCacheConfig();
/*
tokenCacheConfig.setTimeToLiveSeconds(24 * 60 * 60 * 1000); // 1 hour TTL
tokenCacheConfig.setMaxIdleSeconds(24 * 60 * 60 * 1000);    // 30 minutes max idle seconds
tokenCacheConfig.setInMemoryFormat(InMemoryFormat.OBJECT);
tokenCacheConfig.setCacheLocalEntries(true); // this enables the local
*/

此外,lightoauth2文档指出:

"授权服务器发布新刷新令牌,客户端必须丢弃旧刷新令牌并用新刷新令牌替换。授权服务器在向客户端发布新刷新代币后撤销旧刷新令牌。">(emphasis mine)

但我自己的测试表明这并没有发生。例如:

  1. 调用lighteoauth2代码服务(GET),并使用发送到重定向uri的授权代码
  2. 使用授权代码调用light-oauth2(POST:授权代码授权类型)。它将返回授权令牌T1和刷新令牌R1
  3. 使用刷新令牌R1调用light-oauth2令牌服务(POST:刷新令牌授予类型)。它将返回授权令牌T2和刷新令牌R2
  4. 使用刷新令牌R1再次调用light-oauth2令牌服务(同样是POST:刷新令牌授予类型)。它将返回授权令牌T3和刷新令牌R3

步骤4似乎与文档相矛盾,文档称授权服务器在向客户端发出新的刷新令牌后撤销旧的刷新令牌。然而,从上面的步骤4来看,即使在已经发布了新的刷新令牌R2之后,刷新令牌R1似乎也没有被撤销。R1仍然能够获得新的授权令牌。

因此,现在,R1、R2和R3都可以用于获得新的授权令牌,并且可用的刷新令牌集保持无限增长。

我的问题是,这是一个遗漏还是故意的(也许文档应该更新)。如果它是设计出来的,那么它的原理是什么?在我看来

  • 发行这么多永不过期的刷新令牌是不安全的
  • 它造成了维护复杂性,必须手动从数据库中删除刷新令牌,而不是让它们自动过期并被逐出
  • 向数据库中添加这么多新的刷新令牌速度较慢,而且似乎没有必要(例如:为什么每次发布新的授权令牌时都需要新的刷新代币?如果仅以授权码授予类型发布新的刷新标记,则效率会更高)

感谢的帮助

这些都是很好的问题,我认为您已经发现了实现中的一个缺陷。

首先,让我解释一下为什么每次使用旧的刷新令牌时都会发出新的刷新令牌。

众所周知,我们发布的访问令牌是JWT令牌,一旦发布就不能撤销。为了降低访问令牌被盗的风险,我们必须确保访问将在短时间内过期。通常情况下,根据实施情况,时间在5分钟到15分钟之间。这就是刷新令牌出现的地方。它可以持续更长的时间,并且大多数OAuth 2.0实现都提供了一个API,以便在报告刷新令牌从用户窃取时撤销它。根据web应用程序的安全级别,有时刷新令牌需要持续24小时到几个月。我们不想限制它,所以我们删除了刷新令牌的TTL,这样它就永远不会过期。为了最大限度地提高安全性,我们不想一次又一次地重用刷新令牌,因此会在访问令牌的同时发布一个新的刷新令牌。这使得刷新令牌成为一次性令牌,因此一旦被盗,它将不会持续足够长的时间,因为除非应用程序关闭,否则活动会话将不得不每5到15分钟更新一次访问令牌。

您发现以前的刷新令牌仍然可以用于获取访问令牌,这很奇怪,可能是一个缺陷。如果你看看这行代码https://github.com/networknt/light-oauth2/blob/master/token/src/main/java/com/networknt/oauth/token/handler/Oauth2TokenPostHandler.java#L393

旧的刷新令牌将从数据库和缓存中删除。我不知道Hazelcast是否会缓存数据更长时间。我们需要对这个问题进行更多的测试和调查。你能在lightoauth2回购上打开一个问题吗?

由于这是关于安全的,我们需要更加注意所有的细节。让我们弄清楚并把它固定在一起。非常感谢你提出这个问题。

我相信我发现了错误。在com.networknt.oauth.token.handler.Oauth2TokenPostHandler的第423行中,我们有

String newRefreshToken = UUID.randomUUID().toString();

但在431行我们有

CCD_ 2。

tokens.put(newRefreshToken, newToken);

换句话说,代码使用刷新令牌作为更新令牌的密钥。

相关内容

  • 没有找到相关文章

最新更新