Original code:
const token = jwt.sign({ _id: user._id }, process.env.JWT_SECRET, { expiresIn: '1d' });
res.cookie('token', token, { expiresIn: '1d' });
This worked. The token expired in exactly one day from its creation.
The change:
const token = jwt.sign({ _id: user._id }, process.env.JWT_SECRET, { expiresIn: '1m' });
res.cookie('token', token, { expiresIn: '1m' });
I signed out, restarted the server, but still no change! The token still set itself to expire in one day. I'm following a course and when the course instructor made this change in his code, it worked as expected. The token expired in one minute.
I even tried:
const token = jwt.sign({ _id: user._id }, process.env.JWT_SECRET, { expiresIn: '10' });
res.cookie('token', token, { expiresIn: '10' });
Expecting the token to expire in ten seconds or ten milliseconds (I'm not sure what the default unit is) but still the same result. The token still is set to expire in one day.
Is this a cache thing? I have almost zero knowledge on cache, what it is, and how it works, but it is hard for me to imagine that the explanation to this is within the regular bounds of NodeJS coding itself. It would be pretty straightforward if it was. There is no other "configuration" of the jwt module or of how my app handles cookies or tokens in the entire app.
I included the next.js tag because I am using this in a next.js application (although I'm doubtful that is relevant, I could be wrong of course).
I figured it out. Not to fault anyone who commented with a potential solution because there was information missing that I did not realize was there.
This is a NextJS application and there is separate logic on the front end with setting this cookie's expiration date. This expiration date was set to a day and I was not changing it (I forgot it existed). Once I changed it, the change reflected in the browser.
I guess you can set an expiration date for the signed jwt that is separate from the cookie expiration date on the front end. It's redundant and not desirable. I'll have to look for a different long-term solution. I wouldn't find this to be good for real world applications as it makes it difficult to understand what is happening.
Earlier this morning, before I figured this out, the jwt expiration of 10 milliseconds finally started working, but only on the back end. I got a back end error saying my jwt session had expired, which was to be expected. The request made to the back end on my front end page failed because it wasn't authenticated, so I got the expected behavior, but not in the way I was expecting it.
EDIT: I believe I've found the crux of my confusion. The code below is the back end code that was intended to set the cookie in the response, but because we are using separate logic to set the cookie in the front end, I believe this code is not actually doing anything. I've looked over the front end code receives the signed jwt token and no where in there is the res.cookie being referenced. I believe this must have just been an extra line of code the instructor thought was necessary. I've run out of time today, but I'm going to attempt to run the app without this line of code and see if I get them same functionality.
res.cookie('token', token, { expiresIn: '1d' });
Regarding this:
I guess you can set an expiration date for the signed jwt that is separate from the cookie expiration date on the front end. It's redundant and not desirable. I'll have to look for a different long-term solution. I wouldn't find this to be good for real world applications as it makes it difficult to understand what is happening.
I've come to understand that this is an extra layer of security that is valuable to have. The issue was not with the jwt logic on the back end. The issue here is simply that I had extra logic setting up the cookie in the browser in two different places and adjusted the logic that was not being used by the app and browser.