5 ms·

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

by zaphar 2y ago

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.

CuriouslyC 2y ago
Need? Maybe not. But it's a time saver out of the gate.
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 ago
  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.
- angoragoats 2y ago
  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.
  - swiftcoder 2y ago
    > the stored (hashed) password in your database Hashed and salted I hope
    - angoragoats 2y ago
      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.
  - zaphar 2y ago
    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 2y ago
      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.
  - andoando 2y ago
    Auth0 provides a lot more goodies than this though. Password reset, organizations, multiple login flows, etc
    - angoragoats 2y ago
      Yes, and most authentication plugins for web frameworks provide the same things.
      - koliber 2y ago
        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.
swiftcoder 2y ago
> 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
ramesh31 2y ago
>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.
- finack 2y ago
  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.

by zaphar 2y ago

CuriouslyC 2y ago

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

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 ago
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.
angoragoats 2y ago
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.
- swiftcoder 2y ago
  > the stored (hashed) password in your database Hashed and salted I hope
  - angoragoats 2y ago
    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.
- zaphar 2y ago
  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 2y ago
    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.
- andoando 2y ago
  Auth0 provides a lot more goodies than this though. Password reset, organizations, multiple login flows, etc
  - angoragoats 2y ago
    Yes, and most authentication plugins for web frameworks provide the same things.
    - koliber 2y ago
      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.

swiftcoder 2y ago

> 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

ramesh31 2y ago

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

finack 2y ago
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.