2 ms·
Using a 3rd party to login is nice and all but: - if the party and you don't get along anymore, the accounts are dead. Some business are still counting the mon
by sametmax 10y ago
Using a 3rd party to login is nice and all but:
- if the party and you don't get along anymore, the accounts are dead. Some business are still counting the money lost from cloudflare deciding the underlying site is not respecting their conditions anymore. Same for Google translate. Auth is no different.
- if it has a technical failure, it's impossible to login. If you think it never happens, think again. We hear about a failure every year for some big companies. Because you don't have access to the code, you can't implement a quick fallback and must wait until they fix it.
- if their 3rd party account is compromised your site is as well. "Someone pirated my facebook" is something I heard to many time. It just meant that a close person from them maliciously used their account by accessing their computer when they were away, gaining access to everything.
- if their API changes, you need to change your code. Meaning you need to follow up on each providers. This can have a huge cost and the GAFAS really don't care and change their API at will.
- if the user closed their 3rd party account, they can't login anymore. This one is terrible : when I closed my gmail account, I became locked out of many services with not way of recovering them.
And then let's say you have one sass for auth (Oauth provider X), one for the db (firebase), one for map (gmap), one for static files (ES2), one for your messages (CloudAMQP) and so one.
Basically you own nothing in your infrastructure. You have no control on anything, you are dependent of a lot of things, and they all have you "clicked here to agree" on a lonnnng legal text that will update regularly and be affected by market and politics, across various countries.
Your entire business is at the mercy of others.
- jfroma 10y agoAll of those are very valid concerns and I agree with you what I tried to express is that some times developers underestimate what it means asking for a username and password in their websites. For a proof of this, read haveibeenpwned.com. Troy blog is amazing. If you are an startup, it might be better to invest your time in your idea and not poorly implementing authentication on your own. Yes, google might have issues but I am sure they have more engineers dedicated just to that thing, not only coding but also monitoring. > let's say you have one sass for auth (Oauth provider X), one for the db (firebase), one for map (gmap), one for static files (ES2), one for your messages (CloudAMQP) and so one. I hear you, I have been in both sides. When we started we used to use everything as a service because we didn't even understand how to manage some things like a database, as our OPs team grew we started to move things inside our infrastructure sometimes just to be able to restart them on failures. It is a trade-off and I guess it has a lot to do with the service you are hiring, SLAs, etc.