JSON Web Token and the year 2038 bug

Question

JSON Web Token is a fairly recent standard (May 2015) and yet they decided to go for UNIX timestamps in order to represent dates.

Doesn't this expose the standard to a potential Year 2038 problem in the various implementations? Instead, going for something like the ISO8601 seems more future proof.

Why choosing one above the other?

Answer 1

JSON doesn't put a limit on the precision of numbers, therefore the JWT format itself has no overflow issues. It all depends on the implementation.

Some implementations, such as JavaScript, treat all JSON numbers as double precision floating point numbers. While they're not going to overflow until after the heat death of the universe, they will start to become inaccurate in a little under 300 million years, and the problem will get worse as time goes on (problems such as you create a token that expires in one hour, but that value can't be expressed as a double precision float, the nearest value is in 2 hours, so it doesn't expire until 2 hours time).

Other implementations might use 64 bit signed integers. These will overflow in 300 billion years, well after the sun becomes a red giant and consumes the earth.

The only implementations that are vulnerable to the Y2038 problem are implementations that decide to use 32 bit signed integers when parsing the date. Such an implementation would be stupid. It doesn't matter what format you choose, you can't protect against stupidity - and ISO8601 does nothing to help here, because while that may be what appears on the wire, every single implementation is going to parse it into some number of time units since some epoch, since that's the way all computers work with dates and is the only way to practically do calculations such as is the token expired yet. Hence, every implementation, even when using ISO8601, is susceptible to choosing a number representation with to low a precision to handle dates after a particular time, including choosing signed 32 bit integers to represent the date as seconds since 1970, a la the Y2038 problem. It's up to each implementation to choose an appropriately sized number type to represent their parsed dates, which you'll probably find they all do (and if not, you should report a bug).

So, no, there is nothing wrong with JWTs using seconds since the UNIX epoch for dates.