JWT authentication flow


I’m trying to practice authentication with JWT without passport.js.

I’ve created this flow

  • When a user logs in, a jwt is created, saved in the user document on MongoDB. then sent as res.cookie(). with expiration date
  • When the user logs out. the token is deleted from the database and the cookies are cleared from the browser.

But there is a question
what if the user didn’t logout?
the cookie will expire and will be automatically deleted from the browser.
and the server will have no means to know about the token in this cookie to delete it from the database. This will lead to the accumulation of JWT in the database.

I found a possible solution
which is to set the index “expires” to tokens documents.

But isn’t it will cause performance issue in DB?
are there any better solutions to this?
what flow do you follow normally?

Thanks in advance :sunny:

When the user has cleared the cookies or cookie is destroyed (logout/expired) , next time when the user does a CRUD request (GET/POST ) the token will be missing isn’t it ?
Then the user would not be able to access the resource unless using credential again.
This is a way to handle it. No operations needed in DB.

In the front end when the user fails to retrieve/access the resource the back end will send an unsuccessful response 401 or whatever you want.
Based on that you can redirect the user to login page.

Because of your last question.
This is what the front end looks like on one of my apps https://github.com/GeorgeCrisan/SpendingoJS .
I have an older one that does not follow the best implementation but you can see how the back end works, as proof of concept.
https://github.com/GeorgeCrisan/voting-up Funny that someone has forked already once this piece of **** :))

The second one is hosted here https://voting-up.herokuapp.com/.
The first one add .com to the name if you are keen to test around. (make sure I am not getting sanctioned for promoting or something)

1 Like


Yes, Thank you for clarifying.

actually I thought I have to save all created tokens in the DB in each user document.
this was my old point of view (which is wrong)

  • when the client sends the token if it exists in the DB in the right user document, so he will get authenticated.

but now as I understand “I hope I got this right”, I don’t need to store tokens in the database
I just verify the integrity of the signature, the payload of the token, and the expiration date of it.
and if all goes right so the user is authenticated and no need to have a copy of this specific token in my DB to match it with.
if I understood this right so really thank you :sunny:
also thanks for the links, I will definitely read the code to understand this better

You don’t need to store JWT tokens in your database. They’re signed, so any token you receive and decode is guaranteed to be one you issued, without any tampering. And you don’t need to personally verify the signature or the expiration – the JWT implementation will do all that automatically for you, and will throw an error instead of returning an expired or invalid token.

The only thing you might store is a list of revoked tokens so you can force a particular client to log out before its token expires.

1 Like


Really thank you for your reply :sunny:

what could be a possible case that makes a cookie revoked?

“Logout” is a simple example of revoking a session’s token. With a cookie, you just send an expired cookie and it’s gone, but JWT tokens are not usually issued via cookies. If you needed to lock out a user’s account immediately (say, for abuse), you’d want to immediately revoke all their tokens, though that would include their permanent API keys too.

1 Like