DEV Community

Authentication in Node.js with MongoDB, bcrypt, and JWT web Tokens with cookies 🍪.

Ritesh Kumar on August 21, 2021

Adding authentication to an application is one of the most challenging 😖 but also a very important part for developers, but today I will teach you ...

Read full post

Carlos Azuaje • Aug 21 '21

JWT For session is a bad design.

Samson Andrew • Aug 22 '21

Don't do that. It's discouraging!

Next time, try to say kudos for the write-up, then suggest something better 🙂

Ritesh Kumar • Aug 23 '21

🥺 thank you

Ritesh Kumar • Aug 28 '21 • Edited

No this is not a session based authorization it is a token based but what I did is stored that token in the cookie rather than sending them through the Authorization header for every HTTP request we can do in that way too but I thought that cookie one will be easier to understand for beginners.

Abayomi Ogunnusi • Aug 21 '21

Nice post 👍👍...
I tend to use Express: app.use(express.json())

app.use(bodyparser.json()) outputs depreciation warnings here...just my preference though

Samson Andrew • Aug 22 '21

You're right.
The recommended way is to call the methods directly on the express object.

Because...
In the latest version of Express, some bodyParser's methods have been added natively. That's why you don't have to install or require bodyParser again.

Ritesh Kumar • Aug 23 '21

Yes you are right from now i will also use the same thanks for pointing it out 🤍

Maxine • Aug 22 '21

@icecoffee is this the answer ?!

Atulit Anand • Aug 23 '21 • Edited

Here the author is talking about server side authentication.

Ari Kalfus • Aug 25 '21

Please take a look at auth0.com/blog/adding-salt-to-hash... to understand how to properly set a salt. A global value for your application is Not Good. The value does not need to be a secret, but it needs to be unique for every record you are hashing (unique per-password/user/record).

You typically store the salt with the hash either in a row in the same DB table or even prepended/appended to the hash with a delimeter. All that matters is the salt is unique per input.

From the Auth0 article:

A system-wide salt is pointless to mitigate attacks; it would just make passwords longer. A system-wide salt also easily allows an attacker to keep using hash tables. We should hash and salt each password created for a user. That is, we should generate a unique salt upon creation of each stored credential (not just per user or system-wide). That includes passwords created during registration or as the result of a password reset. If the user eventually cycles over the same password, we don't want to give away that the password has already been used.

Ritesh Kumar • Aug 25 '21

Thank you very much learned something new 🥰.

Ari Kalfus • Aug 27 '21

Yeah!

Tanjimul Hasan Tanjim • Apr 11 '22

Can you explain about ":" which used in password:plainTextPassword

Ritesh Kumar • Apr 11 '22 • Edited

I am destructing req.body and storing password as plaintextpassword

you can understand this with this example

Tanjimul Hasan Tanjim • Apr 11 '22

Thanks you so much, I understood well.

Solomon Uche • Aug 23 '21

On the area where you encrypted the password, after destructuring request body, you recreated the password.
Which is supposed to produce an error identifier already exist because const variable cannot be recreated.

Ritesh Kumar • Aug 25 '21

Actually on destructuring the request body i am creating email and plaintextpassword and after that i created const password so there is no recreation 😇 thats why it didn't produced error.

VyRru5 • Aug 21 '21

Why don’t use header authorization bearer in request ? Is the best practices

Ritesh Kumar • Aug 28 '21 • Edited

Yes we can implement it in that way too which will also make it not vulnerable to CSRF but I thought that cookie one will be more beginner friendly 😬.