Change My View: In-house login/registration vs Auth0

Change My View: In-house login/registration vs Auth0
0

#1

In a lot of programming tutorials for setting up user authentication I’ve seen everyone say Auth0 makes everything super easy and for the large part I agree it makes things easier but at a cost, and the tutorials instruct you on using Auth0 rather than making your own system. Here are some concerns of mine, change my view on using Auth0 as opposed to my login/registration system.

  • You are trusting a 3rd party. What stops a rouge employee or a hired corporate espionage agent from going in and abusing internal tools to hijack your website’s admin panel. How could you prevent such an attack? I suppose some extra form of home made 2nd factor of authentication could prevent this, what risks exist, how can they be mitigated.
  • Will Auth0 last forever? One day could they run out of money and cease to exist? How long would it take to recover.

With those concerns being said change my view on why I should use Auth0 like everyone says over making my own login and registration system.


#2

I think no matter which one you use, you have to abstract it away in such a way that when Auth0 goes away you can easily plug in yours or the next best thing.


#3

That’d still take a long time to recover from, beyond that change my view on an employee going rouge, is it really worth the risk?


#4

I wasn’t really commenting on if you should use it or not, just that whichever tool you use should be abstracted away so that you can switch different tools (whether self-made or not).


#5

The likelihood of a rogue employee is small.

The likelihood of you not conforming to industry safety standards and leaving yourself open to attack is much higher.

If scenario 1 happens, Auth0 are liable. If scenario 2 happens, you are.


#6

Is Auth0 opensource? Would developers really be liable?


#7

Probably not liable in a legal sense, but I’d feel better that they were at fault than me, for purely egomaniacal reasons.


#8

Lol and your boss will probably feel better if they are at fault than you.


#9

From the point of view of learning, better to build your own authentication module. It’s always more important to understand the fundamentals: CSS rather than Bootstrap, Javascript rather than JQuery.


#10

I roll my own authorization since not everybody is a member of facebook, twitter or whatever. I can’t force them to become a member of any social network just to register as a user to my site.

That said, have SSL Certs on your server.
2nd, don’t store plain text passwords in the database. Store only the encrypted string in your database. (That means, even you the site operator don’t know their passwords.)
3rd, seed the user’s password. Preferably, this seed is stored somewhere. If you want to invalidate everyone’s user password, all you have to do is change the value of your seed variable. Then everybody’s password will be useless and they can’t login, and they’ll have to reset their passwords to a new one.
4th, since all passwords are encryoted and even the site operator wouldn’t know them… re-sending user’s password via email doesn’t work. If somebody forgets, then they’ll have to assign a new password to their account via a special link emailed to them.


#11

You wrote this in javascript?


#12

C#, MS SQL database and using .NET cryptography library.


#13

I sure hope you mean hashed not encrypted. With hashing it’s not reversible with encryption it is if you know the key.


#14

Yes, I meant hashed. Even me don’t know the user’s password. I can’t mail them their password, they have to reset and assign a new password for themselves if they forgot.


#15

This is a totally legitimate point. The more control we give to third parties, the more exposed we are. If privacy is a concern (and it should be), we ought to avoid Auth0. It’s not so absurdly difficult to set up OAuth on your own server that I’d want to use a third party. It doesn’t even take an angry employee to make this a problem, as the company could be selling user data to other companies, or just handing it over to government entities.

Of course, when working for a company we’ll rarely have any input into whether or not we should use Auth0, but for your own projects, why not roll your own?


#16

5th, You forgot to salt the passwords to prevent rainbow tables.

And that is the point of Auth0

The argument for Auth0 vs roll-your-own authentication is really an argument of whether you think you can remember and implement all of this or you should leave it up to experts.

It really comes down to priorities.

  • Does your application need complete control of security?
    (If an intruder could break down the door easier than picking the lock then the lock is only meant to keep an honest person honest.)
  • Will all of your customers be able to log in with 3rd parties?
  • Are you willing to be liable if your implementation is negligent.?
  • Are you able to remember, or have time to research, the best practices of rolling-your-own authentication?

If you think you are better off implementing your own authentication system that is up to standards then go ahead.

In most of my applications I provide both, a login with email and password and third party logins, so the user can choose if they want another password to remember.


#17

Another factor you should consider if deciding to integrate Auth is also User Experience.

Many services choose nowadays to enable the user to register with (what is at least perceived as) a trusty service (Google, Facebook …) due to how easy it is.

Usability is a major factor of how successful a service will be, and is well known that registration is often perceived as a barrier; that’s why even big companies that spans from e-commerce to videogames provide a means to login using Auth.

To sum it up here’s the relevant part of a medium article by Nick Babich about UX during login:

Pros: Users don’t have to fill out registration form, to create another pairs of username/password and to verify emails, hence can sign up in like 10 seconds instead of 10 minutes. And most important, users don’t have to remember a new usernames/passwords.

Cons: Since the information about the user is loaded automatically it raises a huge privacy concern and not everyone is likely to be happy to share their profile data. For such cases you should have traditional login system running in parallel.

full article.