Hacker News new | ask | show | jobs
by dvektor 697 days ago
Yes, several. This is going to be a controversial one... but it isn't nearly as difficult as people make it seem. You shouldn't roll your own crypto libraries, but storing a bcrypt hash of the users password in the database, and then creating a JWT and setting it in a cookie, or create a session table and store a UUID in the cookie as a key to the session table really isn't that difficult.

Personally I think the problem is we are being sold so many 'conveniences'/solutions these days. They want you to think you cannot safely do it yourself, and on top of that, often times it's actually more difficult just to learn how to use whatever API the convenience that's being sold to us, uses.

You are often better off learning what is really happening under the hood, and solving the actual problem, instead of trying to figure out whatever api/tool that is being sold to you as a convenience. EDIT: to clarify, if you are inexperienced: I recommend learning by implementing both session + JWT auth on a side project, before using hand-rolled solutions in production.

4 comments

This has been my experience as well. I started with tools like supabase and appwrite and after spending so much time fiddling with their APIs, decided to do as this commenter suggested and found it wasn't as difficult as I was led to think.
Bonus points, store meta data about the hash algorithm. That way if you ever need to change it in the future due to a weakness in the algorithm you can validate the password against old metadata and rehash with new metadata and update the record.
Many of the popular password hashes include metadata in the default output already. bcrypt certainly does.
Argon2 as well. Most libraries give you a string that contains all the parameters it needs for hashing.
I'd say that the basic user and session management is easy to implement. The issue is when things get more complicated and your customers want to have single sign on, groups, roles, OpenID and so forth. You can still do it yourself, but at some point you might be spending a lot of developer time on reinventing the wheel instead of working on your actual product. You might also have to build all the associated dashboards for managing all that.
I've done this as well, where I work. There's some talk about replacing it with an off-the-shelf solution, but my service takes one call to issue a token and one call to authenticate it.

The talk about replacing it is with OAuth2, so the result will be that integrating with any service will be more difficult than writing the entire auth service in the first place, but what can you do.