Yes of course. Generally, for a project with a small team, doing the backend for logins yourself is a good way to get yourself hacked or having your customers data leaked at some point. It is difficult to do this type of validation and security testing well. The most likely outcome is that you overlooked something and later pay the price. On a small website I would default to using Google/FB/etc for logins and let them handle the security.
That's pretty flimsy reasoning to allow Google and Facebook to track your users. You "might" have done something wrong. It's unlikely they rolled their own encryption and authentication process. Using well trusted, vetted, local auth libraries is much more preferable than outsourcing your auth for "security reasons" to a third party.
Auth0 adds cost overhead for small projects that is hard to justify. I think the original comment about doing your own logins is overblown and theres still heaps of ways that outsourced logins can be broken from an integration POV.
I, for one, wouldn't ever use a service that requires login via social media or some other platform, especially FB/Google. This isn’t usually a problem, though - I don’t think I’ve ever encountered an app that would impose this. (Maybe apart from services that are specifically built on top of the app that they’re authenticating through.)
It sounds like you’re asserting that any password login must have been rolled by hand from scratch, when in reality there are many great community built password login frameworks for basically any language and tooling combination you can think of.
For example, if I’m using rails I can drop in Devise for a strong community tested user auth system. One that doesn’t let a marketing company track my usage.
Are you thinking the tricky part here is in handling password resets? Because otherwise I've had an easier time with straightforward username+bcrypt(password) in-house versus reliably implementing OAuth2/OpenID/whatever, which has some sharp edges of its own.
On a small website I would default to using Google/FB/etc for logins and let them handle the security.
And that would exclude many, including myself as I refuse to use the "services" provided by rapacious scumbags like Google and FB. Then again, OP is using Flutter, which is a Google jam. I wonder how long it will be before Google cancels it?
All that said, why not suggest WebAuthn[0] or (Google again, short lifetime likely) Firebase instead? Especially since Firebase is a supported plug-in[1] for Flutter?
Rolling your own version is pretty straight forward as a single inexperienced developer. But most people use a framework with batteries included login functionality like password resets / rate liming. If it takes a medium sized team or a team something is off.
Just please don't (only) rely on people having a Google or Facebook account. If they're all that's offered you're excluding a lot of people that don't want anything to do with those two companies.
Comments
Yes of course. Generally, for a project with a small team, doing the backend for logins yourself is a good way to get yourself hacked or having your customers data leaked at some point. It is difficult to do this type of validation and security testing well. The most likely outcome is that you overlooked something and later pay the price. On a small website I would default to using Google/FB/etc for logins and let them handle the security.
That's pretty flimsy reasoning to allow Google and Facebook to track your users. You "might" have done something wrong. It's unlikely they rolled their own encryption and authentication process. Using well trusted, vetted, local auth libraries is much more preferable than outsourcing your auth for "security reasons" to a third party.
One could still use something like auth0 to implement authentication without shelling out to social media.
Auth0 adds cost overhead for small projects that is hard to justify. I think the original comment about doing your own logins is overblown and theres still heaps of ways that outsourced logins can be broken from an integration POV.
I, for one, wouldn't ever use a service that requires login via social media or some other platform, especially FB/Google. This isn’t usually a problem, though - I don’t think I’ve ever encountered an app that would impose this. (Maybe apart from services that are specifically built on top of the app that they’re authenticating through.)
Tailscale comes to mind.
It sounds like you’re asserting that any password login must have been rolled by hand from scratch, when in reality there are many great community built password login frameworks for basically any language and tooling combination you can think of.
For example, if I’m using rails I can drop in Devise for a strong community tested user auth system. One that doesn’t let a marketing company track my usage.
Are you thinking the tricky part here is in handling password resets? Because otherwise I've had an easier time with straightforward username+bcrypt(password) in-house versus reliably implementing OAuth2/OpenID/whatever, which has some sharp edges of its own.
Agree with that. Honestly signup/login is not that hard to implement right, even from scratch.
Also I don’t want FB/Google to know what I login to if I can avoid it.
And that would exclude many, including myself as I refuse to use the "services" provided by rapacious scumbags like Google and FB. Then again, OP is using Flutter, which is a Google jam. I wonder how long it will be before Google cancels it?
All that said, why not suggest WebAuthn[0] or (Google again, short lifetime likely) Firebase instead? Especially since Firebase is a supported plug-in[1] for Flutter?
[0] https://en.wikipedia.org/wiki/WebAuthn
[1] https://pub.dev/packages/firebase_auth
Rolling your own version is pretty straight forward as a single inexperienced developer. But most people use a framework with batteries included login functionality like password resets / rate liming. If it takes a medium sized team or a team something is off.
Just please don't (only) rely on people having a Google or Facebook account. If they're all that's offered you're excluding a lot of people that don't want anything to do with those two companies.