JSON Web Token是一个相对较新的标准(于2015年5月发布),但他们决定采用UNIX时间戳来表示日期。
这难道不会让该标准在实现过程中潜在地面临2038年问题吗?相反,选择像ISO8601这样的标准似乎更加有未来性。
为什么要选择其中一个而不是另一个呢?
JSON Web Token是一个相对较新的标准(于2015年5月发布),但他们决定采用UNIX时间戳来表示日期。
这难道不会让该标准在实现过程中潜在地面临2038年问题吗?相反,选择像ISO8601这样的标准似乎更加有未来性。
为什么要选择其中一个而不是另一个呢?
JSON对数字的精度没有限制,因此JWT本身格式没有溢出问题。一切都取决于实现方式。
一些实现方式,比如JavaScript,将所有JSON数字视为双精度浮点数。虽然它们不会在宇宙热寂之前溢出,但它们将在不到3亿年内开始变得不准确,并且随着时间的推移问题会越来越严重(例如你创建一个有效期为1小时的令牌,但该值无法表示为双精度浮点数,最近的值是2小时,因此它直到2小时后才过期)。
其他实现方式可能使用64位有符号整数。这些将在3000亿年后溢出,远在太阳变成红巨星并吞噬地球之后。
唯一容易受到Y2038问题影响的实现方式是在解析日期时决定使用32位有符号整数。这样的实现方式是愚蠢的。无论选择哪种格式,都不能防止愚蠢的行为-ISO8601在这方面无济于事,因为虽然它可能是传输协议中的格式,但每个实现都将把它解析成从某个时期以来的某些时间单位,因为这是所有计算机处理日期的方式,也是实际进行计算(例如令牌是否过期)的唯一方式。因此,每个实现,即使使用ISO8601,都容易选择代表日期的数字表示形式精度过低,无法处理特定时间之后的日期,包括选择有符号32位整数来表示从1970年开始以秒为单位的日期,如Y2038问题。每个实现都需要选择适当大小的数字类型来表示其解析的日期,你可能会发现它们都这样做(如果没有,应该报告错误)。
因此,对于JWT使用UNIX纪元后的秒数作为日期没有任何问题。
Unix时间戳并不那么糟糕——与解析日期相比,它们绝对可以帮助您简化一堆计算。
在大多数情况下,JWT中的日期声明应该与NOW()
(考虑到exp
声明)进行比较,因此在那里使用时间戳是有意义的。
我不会担心Y2038问题,因为32位系统将面临比发行JWT更大的问题。