I'm building out a website (never did full stack before) and am implementing authentication. It's turning out to be more work than I expected. Is it unreasonable to implement auth yourself with JWTs? You also need to setup email sending for verification which takes more time.
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.<p>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.<p>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.
I have, and the basic username / bcrypted / scrypted password / JWT implementation was quite easy. What I found difficult* was all the accessory quality of life functionalities, e.g. password reset via mail, automated backups, 2 factor authentication, social login etc. You might not want all of them, but email verification / reset is kinda the expected baseline and it means you have to use an external mail-sending system anyway.<p>*difficult not as in "hard to implement", more as in "lots of moving parts, hard to maintain"
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 <a href="https://blog.ploetzli.ch/2024/should-i-use-jwt-for-authentication/" rel="nofollow">https://blog.ploetzli.ch/2024/should-i-use-jwt-for-authentic...</a>). 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: <a href="https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html" rel="nofollow">https://cheatsheetseries.owasp.org/cheatsheets/Authenticatio...</a>
For a simple website JWTs are almost definitely an overkill (you would get all the drawbacks for none of the benefits). A session based authentication with some libs from your ecosystem for the crypto parts and a nice intro on how to combine them together could be the perfect thing for you.
If you are using python and flask for building the web application, then there is a well defined tutorial on implementing user login and password.<p><a href="https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world" rel="nofollow">https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial...</a>
I had to implement my own because all the alternatives were some combination of 1. Crap 2. Over complicated for my needs 3. Ridiculously expensive<p>Unless you are more experienced and smarter than average engineer working on a 3d party solution - you should build your own only for educational purposes.
As others have pointed out, rolling your own simple username-password auth isn't too hard. As you go forward, you might need to add other things like 2FA or social login or SAML, and those things aren't exactly hard either (there's TOTP validation libraries in most languages I think, and for SAML you can use Jackson [1] which translates it to OIDC for you). It is quite boring though.<p>[1]: <a href="https://boxyhq.com/docs/jackson/overview" rel="nofollow">https://boxyhq.com/docs/jackson/overview</a>
What language/framework are you using? Typically you would implement your own authentication for learning the nuts and bolts of auth, but never for a production/live system on the web.<p>You would either use something like Firebase Auth or the built-in one that comes with your framework of choice. Identity in .NET core for example.<p>On the topic of auth, and as an aside, wondering if anyone has used a UUID + API key combination to do auth instead of JWT/cookies?
Yes, 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.<p>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.
Yes. On login issue a single session auth token to be stored in the header and passed for all future API requests.<p>You should consider one of the many frameworks that handle this sort of thing for you (every language has them.)<p>It is unclear from your comment how you might be helped.
Oh yeah. I built the oauth 2 stack at my company. Just read through the spec and made sure I did everything, and was obviously very careful.<p>It was pretty boring and grinding. For a personal site, I’d use something off the shelf for sure.