JSON Web Token和2038年的bug

Question

JSON Web Token是一个相当新的标准（2015年5月），但他们决定选择UNIX timestamps以represent dates。

这是否会在各种实现中将标准暴露给潜在的Year 2038 problem？相反，寻找类似ISO8601的东西似乎更具未来性。

为什么选择一个在另一个之上？

Answer 1

JSON对数字的精度没有限制，因此JWT格式本身没有溢出问题。这完全取决于实现。

某些实现（例如JavaScript）将所有JSON数字视为双精度浮点数。尽管直到宇宙热死后它们才不会溢出，但在不到3亿年的时间里它们将开始变得不准确，随着时间的流逝，问题将变得更加严重（诸如您创建令牌的问题在一个小时内到期，但该值不能表示为双精度浮点数，最接近的值是在2小时内，因此直到2小时后才到期。

其他实现可能使用64位带符号整数。它们将在3000亿年内溢出，很久之后太阳就变成了红色巨人并吞噬了地球。

唯一容易受到Y2038问题影响的实现是在解析日期时决定使用32位带符号整数的实现。这样的实现是愚蠢的。不管选择哪种格式，都无法避免愚蠢-ISO8601对此无济于事，因为虽然这可能是实际出现的情况，但每个实现都会将其解析为一定数量的时间从某个时代开始就开始使用单位，因为这是所有计算机处理日期的方式，并且是实际进行计算的唯一方法，例如令牌是否过期。因此，即使在使用ISO8601的情况下，每个实现也容易选择精度较低的数字表示形式来处理特定时间后的日期，包括选择带符号的32位整数将日期表示为自1970年以来的秒，这是Y2038问题。每种实现都取决于选择一个适当大小的数字类型来表示其解析日期，您可能会发现它们都已解析（如果没有，则应该报告错误）。

所以，不，自UNIX时代以来，使用秒的JWT并没有什么问题。

Answer 2

Unix时间戳并没有那么糟糕 - 它们肯定会帮助您简化一堆计算而不是解析日期。

在大多数情况下，JWT中的日期声明应该与NOW()进行比较（考虑exp声明），因此在那里使用时间戳是有意义的。

我不担心Y2038错误，因为32位系统比发布JWT有更大的问题。