It's actually very easy to implement your own authentication. You should use either Argon2 or Bcrypt to store passwords. If the website is small, you shouldn't use JWTs (see https://blog.ploetzli.ch/2024/should-i-use-jwt-for-authentic...). Ideally, you should use an encrypted HttpOnly cookie with SameSite=strict, etc. which you can optionally sign just like you would sign a JWT although that's unnecessary. You might also find this useful: https://cheatsheetseries.owasp.org/cheatsheets/Authenticatio...
Has anyone built their own authentication system?
21–26 of 26 posts
Re: Has anyone built their own authentication system?
#22Yes, multiple times. But if you'd like to build an MVP you can't go wrong with a SaaS auth service to get you started and transition to something else. Even better nowadays, there are multiple SaaS/starter kits you can use (most are paid) that remove all these chores and you can get down to your domain flow.
I know a number of companies rely on Auth0 et al because it looks safer to customers, and in case of a breach it's good to be able to say that you are relying on industry standards etc.
However, my own experience is that the API's are in fact more complex to deal with than just setting it up yourself. So at least for MVP's, I wouldn't recommend it.
Re: Has anyone built their own authentication system?
#23Yes, 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 prob…
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.
Re: Has anyone built their own authentication system?
#24Yes, 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 prob…
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.
Re: Has anyone built their own authentication system?
#25It's actually very easy to implement your own authentication. You should use either Argon2 or Bcrypt to store passwords. If the website is small, you shouldn't use JWTs (see https://blog.ploetzli.ch/2024/should-i-use-jwt-for-authentic... ). Ideally, you should use an encrypted HttpOnly cookie with SameSite=strict, etc. which you can optionally sign just like you would sign a JWT although that's unnecessary. You might…
> You should use either Argon2 or Bcrypt to store passwords.
I've used randomly salted SHA512 to create a stored password. What's wrong with that?
Re: Has anyone built their own authentication system?
#26It's actually very easy to implement your own authentication. You should use either Argon2 or Bcrypt to store passwords. If the website is small, you shouldn't use JWTs (see https://blog.ploetzli.ch/2024/should-i-use-jwt-for-authentic... ). Ideally, you should use an encrypted HttpOnly cookie with SameSite=strict, etc. which you can optionally sign just like you would sign a JWT although that's unnecessary. You might…
> You should use either Argon2 or Bcrypt to store passwords. I've used randomly salted SHA512 to create a stored password. What's wrong with that?
As long as the salt is an actual salt (i.e. unique random value for each user entry), it's not a disaster, but it's going to significantly easier to crack a password that was hashed once than one that's gone through hundreds of thousands of hashing iterations or used a more advanced algorithm like argon2 which is more resistant to cracking by design.
The recommendation that I'm familiar with is to increase the cost as high as your servers can reasonably bear. High number of iterations and more advanced algorithms will increase the load on your servers but in turn they'll also provide much better protection.