时钟偏差和令牌
Posted
技术标签:
【中文标题】时钟偏差和令牌【英文标题】:Clock skew and tokens 【发布时间】:2018-04-19 13:38:36 【问题描述】:我需要帮助来了解时钟偏差的工作原理。我们定义时钟偏差来处理两方之间的时间变化。但是,我的困惑是:
-
我们在令牌本身中拥有令牌创建时间和过期时间等所有信息
可以验证令牌
在服务器上创建令牌
那么,为什么我们需要时钟偏差?谁能给我举例说明它的工作原理以及在哪些情况下会导致问题或好处?
【问题讨论】:
我必须设置以保证调整计算机时钟的用户更改小时/分钟而不是设置正确的时区(例如,当 DST 开始时,将小时更改为 +1 而不是使用 DST 标志或正确的时区) 仍然可以登录网站,它会影响浏览器中的令牌验证,因为它会使计算机的 UTC 时间戳不正确,然后浏览器总是将令牌视为过期。 【参考方案1】:让我们考虑一个短暂的访问令牌。当我向服务器发出请求时,服务器将检查我的令牌是否已过期。它如何检查它是否知道令牌的创建时间以及现在是什么时间。大多数访问令牌在一小时后过期,但这实际上取决于它在身份验证服务器中的设置方式。因此,如果令牌是在一个多小时前创建的,它就会过期,并且会通知用户。这就是我们尝试确保服务器与NTP 同步的原因。
让我们首先考虑一下究竟什么是时钟偏差。如果我们有两个身份验证服务器怎么办?你怎么知道他们会有相同的时间?如果他们实际上离开了几分钟怎么办。一台服务器将返回令牌已过期,而另一台则不会。如果您是一家小公司,这可能无关紧要。
现在考虑您是否是一家大型搜索引擎公司,其服务器遍布全球。可以说它是 2016 年的秋天,夏令时开始了。现在你有一些服务器在一个时间运行,而其他服务器在另一个时间运行。也许只是也许某个国家决定在他们开始夏令时时改变,并且大量代币无缘无故地失效。 免责声明我不为上述搜索引擎公司工作。我只是看着这件事发生,这是我对发生的事情的理论。
为什么我们需要时钟偏差。
您不需要它,但如果您有两个身份验证服务器,您可以拥有它。所以你可能应该处理它。 https://softwareengineering.stackexchange.com/a/245182/160992
【讨论】:
不错的答案,但时钟偏差也发生在同一台机器上。我有 IdentityServer4 和使用 IdentityServer 的桌面应用程序,所以它们都在同一台机器上。 IS4 在本地主机中。令牌没有按照设置过期。添加时钟偏移设置时已修复!你能就这种情况提出一些建议吗? 很抱歉,我从未见过它发生在同一台机器上 @newbeedeveloper 它发生在我的 ids4 同一台机器上。你修改了什么设置来修复它? 嘿,我也面临同样的问题。有人修过吗? @NoymulIslamChowdhury 你有什么问题?【参考方案2】:好的,所以Clock skew
没有发生在您的机器上。默认情况下,clock skew
设置为 5 minutes
。这就是jwt token
没有在预期时间到期的原因。
【讨论】:
那么到底什么时候到期?【参考方案3】:这意味着在 ValidateLifetime 模式下设置令牌过期时间的容差。ClockSkew 意味着对这种不一致的容差(在令牌发行者与其消费者的时间和时间之间)。
时钟偏差量指定验证 exp 和 nbf 声明时服务器和客户端时钟之间允许的时间差(以秒为单位)。推荐的默认值为 5。
【讨论】:
【参考方案4】:Microsoft JWT 验证中间件存在时钟偏差。默认设置为 5 分钟,不能小于(300 秒/5 分钟)
有一个名为 ClockSkew 的令牌验证参数,它获取或设置在验证时间时应用的时钟偏差。 ClockSkew 的默认值为 5 分钟。这意味着如果您没有设置它,您的令牌将仍然有效长达 5 分钟。 如果您想在确切的时间使您的令牌过期;您需要将 ClockSkew 设置为零,如下所示,
services.AddAuthentication("Bearer").AddJwtBearer("Bearer", options =>
options.Authority = "https://localhost:44347";
options.TokenValidationParameters = new TokenValidationParameters
ValidateAudience = false,
ValidateLifetime = true,
ClockSkew = TimeSpan.Zero
;
);
【讨论】:
以上是关于时钟偏差和令牌的主要内容,如果未能解决你的问题,请参考以下文章
正在使用 microtime() 生成密码重置令牌不好的做法