Have you ever wondered how authentication works? What’s behind all the complexity and abstractions. Actually, nothing special. It’s a way of encryp...
For further actions, you may consider blocking this person and/or reporting abuse
Hvala for this handy reference!
I have implemented JWT for my Todo-List-App, to be able to also make a CLI for it. The web-frontend, and the API for Ajax-calls, work with sessions/cookies.
After I got it working, I realized that I can also use cookies for the CLI (Golang has CookieJar for this).
Now I wonder whether I should prefer JWT over Cookies for the CLI. Is there any best-practise for non-webapp-authentication? (So far I think I'll stick to sessions, so I don't have to maintain two auth-methods in the node-app.)
Hvala for liking it!
Yeah, I'd also suggest using sessions. I believe it's the best and safest way to implement auth. In the end, ease of use and security are what's most important.
I'd put the JWT in a cookie and expand the middleware to check if there is one, too. The it works like a session, it's more secure (keyword: session hijacking)
Thank you for your reference. One security minded remark: You should never return a "user not found" message (or that the password is wrong) to the user. This is called an account enumeration vulnerability. This would allow someone else to find out if a user exists in your system, which then allows them use this for a spam list, phishing and other things.
It's better to just say the provided credentials were not correct or something else sounding more generic.
This is also important for password reset functions, where it's better to just send further instructions to the provided e-mail (if an account exists) and don't tell the browser/client you found/didn't find an account with that e-mail address. Just say, that if an account exists with the provided e-mail address, check your inbox.
Yes, I agree fully. For demo purposes, I've made the explanations and code examples as simple as possible. But, I'd always suggest only returning a vague message such as "The credentials you entered are incorrect."
The password reset you mentioned is also a very delicate matter. I would never risk having it any other way than through e-mail instructions.
Thanks for this feedback and I'm glad you liked the article. :)
Great article but I still have some doubts.
1 - To create the token you have passed user._id parameter, but to check using verify function you haven't passed the same parameter. In this case can an user use a token of other user?
2 - Is possible to add inside token other parameters to check after, like a list of permissions? In your example all users have the same access, but in a case where different users has different access levels, we need a way to check it inside middleware function, right?
Thank you, I'm glad you liked it.
This act of verifying users is called authorization. It means that a certain type of users has access rights to some resources. The verify function is checking whether this user has the access right. The tokens are only as a way of granting permission to the resource.
Yes, you can add more properties to the object you sign the token with. Such as a roles array. But all the checking will be done inside a middleware function. However, beware. Never sign the token with the whole user object. This is very dangerous as the token can end up having the user's password. That's not something you want happening.
Absolutely loved this and will be using this as a reference the next time I’m working on a project
Thrilled you liked it!
Thank you so much!
You're very welcome!