You can add this type of thing to your validation code: exp has to be set, can't be in the past, and can be no more than x time in the future (where x is somewh

You can add this type of thing to your validation code: exp has to be set, can't be in the past, and can be no more than x time in the future (where x is somewhere between what you're actually signing now and the largest value you could ever conseivably want to use without having to push an update to this app). One of the biggest challenges with using JWTs is really all these gotchas that you have to think about. This isn't dissimilar to the infamous `alg:none` fiasco. In this case, it's not really about protecting against an attack, but forcing the developer on the other end to think about it. Their quick initial code that doesn't bother setting exp or has it hard-coded to 1000 years in the future will never work, so it had less chance of being left in to cause a security issue later.