Hacker News Reader

Comment by ramesh31 | Hacker News Reader

So then why does Auth0 use JWTs for everything..?

Because their business is auth as a service and because their database is not your database and they don't want you hitting their database directly.

A similar question to the articles is whether you actually need Auth0 or not. You might but then you are offloading all the issues of JWT's to Auth0 so in theory, probably not in practice, you don't have to worry about those.

For many apps however. You probably don't really need Auth0.

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?

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

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.

> the stored (hashed) password in your database

Hashed and salted

I hope

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.

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.

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.

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

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

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.

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

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.

Need? Maybe not. But it's a time saver out of the gate.

> You probably don't really need Auth0

And there's a good chance you really don't want to pay for Auth0. Their Enterprise tier becomes very expensive as your MAU starts to grow

>but then you are offloading all the issues of JWT's to Auth0 so in theory, probably not in practice, you don't have to worry about those.

Yeah, exactly. I get to offload everything to Auth0 instead of maintaining a cryptographer on our payroll to reimplement a solved problem. Hand rolled OSS authz/n may work for individual projects, but there's no other reasonable solution in a modern enterprise environment with SSO.

You don't need a cryptographer on payroll to install and configure an SSO library. Maybe your developers aren't skilled enough to do that, but it is not a challenge for a proper senior developer.

Well, I imagine, if we're taking the opinion of the article as fact, Auth0 must be able to scale to enterprise levels, i.e. have so many long-tail accounts that it approaches Facebook/Google scale.

JWTs are best practice for OAuth as it can transport claims. It’s up to your application if you continue to use it after the initial flow. You are fine to convert it, but most apps don’t as it’s easier.

JWT is a great way to authenticate the person who is trying to log into your app. Once authenticated, you are free to exchange the JWT token for a sessionid.

The whole point of the article was that JWT is unnecessary if you’re just using it to get a session token. Why not just cut out the middleman?

Reply on news.ycombinator.com