[angoragoats]

Submit 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.

[andoando]

Auth0 provides a lot more goodies than this though. Password reset, organizations, multiple login flows, etc

[angoragoats]

Yes, and most authentication plugins for web frameworks provide the same things.

[koliber]

If 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]

There are plenty of ready made SAML libraries out there that should work with whatever web framework you like to use.

[koliber]

There 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.

[zaphar]

There 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]

Yes, 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.

[swiftcoder]

> the stored (hashed) password in your database

Hashed and salted

I hope

[angoragoats]

Technically 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.