4 ms·
As someone that is just attempting to get a better understanding of this aspect of a tech stack, when you say many apps don’t need Auth0 what is the actual alte
by FerdSlav 2y ago
As someone that is just attempting to get a better understanding of this aspect of a tech stack, when you say many apps don’t need Auth0 what is the actual alternative for the whole user authentication story?
- zaphar 2y agoMost web frameworks come with out of the box authentication plugins that will use your own database. It's plenty good enough and you still don't have to roll your own. Adding an external service adds complexity that you may not want to pay for later.
- angoragoats 2y agoSubmit a username and password via a form over https. Your backend hashes the password, and checks it against the stored (hashed) password in your database. If it matches, the user provided the correct password. Create a session token (random string is fine) and return it to the user via a cookie in the reply. Store the session token in your database, such that you can map it to the authenticated user. Then on each subsequent request, look up the session token and you have your logged in user. This is how apps were doing it for literally decades, before JWT was invented. And most web frameworks will do all of this for you.
- swiftcoder 2y ago> the stored (hashed) password in your database Hashed and salted I hope
- angoragoats 2y agoTechnically yes, of course, but if you’re using an algorithm that requires you to manually worry about salting then you’re probably doing it wrong. Hence, “hashed” with an algorithm like bcrypt or scrypt is good enough.
- zaphar 2y agoThere are some subtleties here that are important to know[0]. Which is why I generally advise people to use the framework provided code for this. 0: Such as use a secure hash like sha256 or blake2 instead of md5.
- angoragoats 2y agoYes, though I would recommend something that is resistant to timing attacks such as bcrypt. And this was why I mentioned frameworks in my last sentence. My intention wasn’t to give a comprehensive soup to nuts guide for what to do; instead i was giving a high level overview.
- andoando 2y agoAuth0 provides a lot more goodies than this though. Password reset, organizations, multiple login flows, etc
- angoragoats 2y agoYes, and most authentication plugins for web frameworks provide the same things.
- koliber 2y agoIf you write a B2C app, there is a good chance that you might not need Auth0 and the functionality of the authentication, authorization, and account management tools in your framework suffice. If you plan on selling B2B you might need to support SAML and other enterprise federated login mechanisms. There, the scales tip in my book and I would go with Auth0. It’s expensive to support SAML in-house.
- angoragoats 2y agoThere are plenty of ready made SAML libraries out there that should work with whatever web framework you like to use.
- koliber 2y agoThere are plenty of libraries. But supporting a production SAML service provider takes a lot of work. I've done this before. The first library I used had a horrible security issue that remained unfixed. We switched to one that seemed to be secure. Implementing SAML is non-trivial. Adding automated testing is also not something that required more senior people on our team. Getting engineers to understand how SAML work takes effort. Also, about one out of five SAML IdP's are unconventional in some way. They are a royal pain to support. The support burden of SAML is much higher than expected. Paying for Auth0 is cheaper than the engineering cost of supporting SAML, even with one of the existing libraries you refer to.