JWT.sign expiration property is not well documented

[ebeloded]

We have been using the JWT utility to sign our secure URL tokens. Recently our thumbnails started disappearing. It turned out that expiration was not set in an expected format.

By reading this document, I assumed that expiration property is the same as exp on the JWT token, so I've been setting it to the UNIX epoch value of desired expiration date.

There was no errors during signing, so I didn't expect things to go awry.

After digging, I found that expiration on JWT.sign is passed to expiresIn on jsonwebtoken. expiresIn is clearly a better name and wouldn't have caused the issue.

May I suggest renaming the property to expiresIn to avoid this confusion for others and maybe add some JSDocs for the prop.

expiresIn in jsonwebtoken accepts value in vercel/ms format, which can be a number representing seconds, or a string. A string can be a number with units: "7d", "3h", etc. If a string is a number without units then it is considered to be ms. This is what happened in my case - I was providing stringified UNIX timestamp, which was turned into ms duration.

PS. I know that reference doc highlights that the default value is '7d' and if as much was mentioned in the docs or JSDocs, the problem could have been averted.

[dylanjha]

@ebeloded Thank you so much for raising this. Makes complete sense. At the very least we can document this better in the README (even by pulling in examples from the reference doc).

We'll consider your suggestion for re-naming, I could see how that could help. Without introducing API breakage and a major version change we would have to support both expiration and expiresIn, so we'd have to do it in such a way that doesn't cause too much confusion.

We'll get this fixed, and thanks again for surfacing

[dylanjha]

Updated with better documentation & types in Version 8:

https://github.com/muxinc/mux-node-sdk/releases/tag/v8.0.0