Hacker News Reader

Comment by bgdam | Hacker News Reader

It seems Facebook mandates the use of the SDK if apps wish to provide 'Login with Facebook' functionality. My question is this - Why would any company include this SDK, which is basically spyware into their apps, simply in order to have a slightly easier login flow? Is implementing a user authentication system really so complicated, that you guys think it is okay to give away control of your users, and even your app's ability to even startup without crashing, to a third party company over whom you have no control, who has no obligation to not break your app at their whim?

View on HN

> Why would any company include this SDK > Is implementing a user authentication system really so complicated

"Login with Facebook" isn't popular because it saves developer time. It's popular because it massively reduces signup friction which results in higher conversion rates. These things are super important. We offer Google login with our only consumer facing app[1] and we see a solid 40% of accounts use that method vs. email. I would venture a guess that a sizable minority, bordering on majority, of those accounts would simply never sign up in the first place without some sort of SSO.

I agree with your sentiments and frustrations, but whenever something seems to be too ridiculous to be true (as this might seem to some devs) there's often something else at play.

[1] Squawk - Walkie Talkie for Teams https://www.squawk.to

Personally I use login with Google because: 1. I “trust” google auth - I know they won’t store passwords in plaintext or anything funny like that 2. It’s a centralized place I can use to rotate my keys 3. I can revoke accounts

Signing up via email on each site means a password manager entry at a minimum, and probably no 2FA, or brute force resistance.

I never use login with Google, because if one day some automated process decided to suspend my account then I'd also lose access to all other systems I was using Google for authentication.

You're basically at the mercy of getting hold of google's nearly nonexistant support to get this resolved

As a user with a $19/year Google One subscription, I find Google support quite easy to reach.

But will they still treat you that way after an errant classifier puts you in the wrong bin?

Unless you get auto-suspended and end up receiving non-answers as explanations until you drum up enough twitter attention for a non-outsourced support employee to revert the decision and say "We identified an error that automatically suspended your account and have resolved the issue" a week of frustration later.

I also pay $dollars/year for Google. Turns out, when you start paying people money, and it becomes a legal liability for them to screw up, they act...better?

I have a one-click button to download all my data from Google (which turns out to be an absolute pain because it's in the ~100s of GB range).

Yeah, good luck with that button after they've pushed theirs first.

We know Facebook uses data they gather for competitive product reasons. I wonder how important Facebook’s insight into signup and login auth for upstart products (like TikTok or fortnite) was for internal intelligence on where the wind is blowing / compete / acquire targets.

FB SSO isn’t really an option for an early stage consumer product, but if it were I can see Potential benefits to the products that are succeeding avoiding sharing real-time success metrics with FB.

Presumably, Apple is also influenced by data like this via the App Store.

For example Apple probably pays attention to Autosleep and other sleeping apps in deciding to build it into WatchOS.

>It's popular because it massively reduces signup friction which results in higher conversion rates

does it tho? I know that is the sales pitch but is that really the case in 2020 with facebook's login?

Yes. HN isn’t real life. Billions of people still use FB.

the visitors for work definitely aren't from HN. It had such a little affect on conversions and sign ups it was later removed.

Agreed. Email/password login can end up being less privacy conscious because they might sell your email and store your pws in plaintext

It's interesting how modern tech companies took Microsoft's "Embrace, Extend, Extinguish" playbook and ran with it. OAuth was supposed to be a standard that allowed interoperability but instead each company enforces the use of their own OAuth SDK/variant (see also Login With Apple).

Debatable. You could implement the login with Google/Facebook/... APIs and not use their official clients, but many companies don't bother.

It's apparently forbidden to implement the API directly without using the SDK when developing a native app.

https://github.com/facebook/facebook-ios-sdk/issues/1385#iss...

What about https://www.keycloak.org/? Is it any good for such solution to half-own OAuth provider?

If you are an enterprise and need to set up some way to do OpenID Connect/Oauth2/SAML 2... yes.

But I would not use it in a consumer facing product.

Can you clarify why not and what would you recommend? I am java developer who is developing side project which is using keycloak for user management. I find it awesome I can plug invarious oath providers (fb, google etc...) While still using my own registration workflow. Quite easy to plug it in my project as well

Ah, if you are using Java it is probably easier to use/develop for. One of the issue I've found is that the REST API is not well documented at all, and using it from an app perspective is not intuitive at all when you are trying to use it from applications that are not Java based.

oh alright... I thought there was more to it.

My websites have traditional email+password signup forms with Facebook and Google singup buttons beneath the form fields. Over 50% of new users use the social buttons instead of email.

https://hunches.app/login

Speaking as a user, I strongly prefer OAuth login whenever possible, so I don't need to manage a new account. I trust the security of big players like Apple, Google, etc. a lot more than random app/website developers. There is some range of value (to me) of services where I will be willing to log in/sign up with an existing OAuth account, but I will not bother if I have to make a new account.

That said, which one it is matters. My order of preference is: Apple, Google, more minor players like GitHub, and way at the bottom of the list, I won't use Facebook's.

What security do you get from them that you don't get from a password manager and a random password for every service? I specifically avoid all external OAuth flows for my personal accounts because there is almost always an extra data grab associated with it.

I agree. Given randomized passwords I don't see any risk with individual sign-ups rather than login partners. I will not sign up for a site/service if it only uses login partners for authentication.

Password managers have a few problems. Sometimes they just don't work well (e.g. banking sites that partially obfuscate your username really confuse them). Sometimes websites make it hard to copy and paste passwords. Apps don't always work with password managers, requiring manually retrieving the password. But mainly, password managers are inherently a bit scary as a single point of failure. You might say that OAuth has the same problem, but I think it's better because no passwords are stored anywhere (even if encrypted), and I use a hardware 2FA key for my preferred OAuth account.

I think the concern about "data grabs" is a bit overblown. I don't believe the OAuth logins that inform you of what information is being shared is lying, and if I don't like what is being shared I won't use it.

> banking sites that partially obfuscate your username really confuse them)

Is there a bank allowing sign in by Facebook/Google?

> Sometimes websites make it hard to copy and paste passwords.

Yes, and that's why password managers do autofill.

> Yes, and that's why password managers do autofill.

There are a ridiculous number of websites and apps that support neither password paste nor autofill.

How does a website control autofill if the password manager extension does it?

Some stupid websites do block paste, but one can use an extension to force enable paste everywhere, which IMHO is required for one's sanity.

It seems like when websites are just janky and/or non-standard, password managers struggle to understand what fields are username/password fields, or whether it is a login vs. signup vs. password reset form, etc.

To me, installing weird one-off extensions is a far bigger surface area of risk than just using OAuth.

Do password managers work inside native apps? That's the number 1 place I use sign in with Google/Apple.

There's an accessibility service that my password manager installs that allows it to autofill native apps.

I don't know the details of what is going on here but it sounds very sketchy. I vastly prefer an OAuth login to installing a native app, let alone one that appears to have very deep system access, and access to all my passwords at the same time.

Using the Lastpass accessibility service on Android only works about 40% of the time for me.

Over half the times I go to use it I sit there trying to trigger it a few times, then give up and have to go and copy / paste the password from the app.

Do you realize you still have to trust the developer implemented their side of oauth correctly? It's not like Google is sending engineers to every implementor to verify that.

Well I don't give the app developer my password, and Google limits the information that they can get about my account on their end. What could a malicious or incompetent app developer do to my Google info?

What use does an app developer have for your password to their own service?

You can lose your data you put to the service, obviously, if someone can get over the broken oauth implementation.

Facebook SSO is extremely convenient for the end-user: most people have an FB account and it's literally three clicks tops to get logged in, vs manually filling out a registration form, thinking of/remembering a password, confirming the email address...

Also, it cuts down on support requests of the type "can you reset my account password?" / "can't login" massively.

Login with Facebook tremendously reduces friction on signup. We get a verified email that we can trust, the name of the customer and a profile photo that automatically renews. But even more important we dont need to ask for a password.

We can also ask for more, such as phone number (we dont ask).

Login with Apple is coming for them, don't worry. Only a matter of time before Apple makes that even stricter and more dominant. I doubt Facebook's argument to the antitrust board will be compelling as Apple masks login data for the app and data broker, while Facebook only wants to aggregate it.

I fear Login with Apple is another poison pill. Sure it's better than some of the current alternatives, but if it's suddenly in Apple's best interest to abuse their position for data gathering, they will.

Then it'll be ironic if an antitrust lawsuit turns into court ordered or legislative wins for user privacy and data-property.

Yup, they’ve introduced APIs in iOS 14 to make it easier to convert a regular login to “Sign in with Apple”:

https://developer.apple.com/videos/play/wwdc2020/10666/

As an Apple ecosystem user, I’m very much looking forward to Sign In with Apple replacing most of my password manager entries.

I want a one click “upgrade” path from email/password to Apple managing the auth.

As someone who uses Apple products occasionally (currently on MBP, used iPhones in the past) I doubt I would switch even if I went all in on the Apple ecosystem again. Their devices and software have annoyed me in the past to the point where I made the switch - anything Apple specific like this makes it a PITA move to a different platform.

Google isn't perfect either - there is a low but realistic chance that they could kill my account at any time with no support options and I'm looking in to ways to protect against this while retaining the benefits - but in practice switching between mobile platforms and all desktop OS-es works like a charm. I use sing-in with Facebook when Google isn't an option. I'm really not concerned with data tracking - it's omnipresent at this point - not worth the energy to think about personally.

No different than Google sign in while having a hardware ecosystem

> Login with Apple is coming for them, don't worry

That's an even greater cause for worry and I fear what will come of this, I would treat their login SDK as the same poisoned chalice that the Facebook login SDK is. Worst - they're effectively forcing app developers to introduce it if they have any kind of social login in their apps, which is an incredibly dick move. Any other company doing this would get negative attention but in our collective hypocricy we keep painting this in a positive light. It absolutely is _not_ a good thing... but this is HN.

I definitely agree with you that this is not a good thing and that Apple is pulling a 100% certifiable dick move by doing this. Who in their right mind would want to implement an email authentication method that just paid out 100k because someone found out they weren't actually authenticating emails. I mean come on... I'd love to see Apple eat their own dog-food on this one and then we could see if it's really ready for prime time.

Seems like they're using it on all of their websites.

So what if you choose to mask your email?

What happens to all your connections if you stop owning Apple devices?

Sounds like a nice way to keep you locked into a very expensive ecosystem.

On the flip side, people used to argue for SSO as a privacy/security feature - rather than sharing your email and creating passwords with every site, just let a trusted intermediary like Google/Facebook handle those nasty details!

They still get your email with SSO. And name, profile pic too. Which they don't via the normal method.

With SSO via Google, FB, you have to agree to share data with them.. email is a thousand times better

That’s not true of Apple which means it’s not true of all SSO. Sometimes users are offered a choice of claims. It’s allowed, just rarely implemented.

> With SSO via Google, FB, you have to agree to share data with them

Not sure about Google, but with FB you can choose which information to share with the site.

But doesn’t that mean if it gets compromised (which I think one popular one did a while back?), then you’re basically screwed for every site you used it with?

Personally, I always use email, plus 2FA when available. I don’t trust “single” sign-ins anywhere - I’d rather control the access to the credentials myself.

This is why FIDO2 is considered a strong alternative to SSO, and, in some cases, persistent session cookies. That said, the likelihood of a site getting compromised is a lot higher than the odds of, say, Google getting compromised. And Google could just deny your logins on unfamiliar devices. Which would cause other problems, but is more likely to happen with Google doing the authentication than at a small random site that doesn’t know what devices I regularly use to begin with. There’s always trade offs of course.

Just use single-correspondent mail addresses for signing up, i.e. weirdwebsite-myname@example.org and strangesite-myname@example.org (using a hyphen instead of a plus sign to get past unhelpful mail address sanitizers), add a regex for * -myname to /etc/aliases and you're set. You don't need to set up special addresses, the regex alias will make sure the mail ends up in your INBOX. I've done this for more than 20 years without being inundated in spam, I never use my 'real' address for interaction with others than friends and family.

Because everything is a tradeoff, and often having a good conversion rate is higher on your priority list than a lot of other things...

I'm pretty sure it's not about it being hard to implement, but also about reducing friction to sign up/in.

I'd personally never use sign in with Facebook, but for nearly all dev related services I prefer sign in with GitHub over creating another account somewhere.

It also reduces the burden on security, you no longer have to think about where to store the usernames and passwords, how to hash them, how to compare the hashes to the plaintext password in constant time, how to prevent brute force attacks, how to prevent csrf and more. There is a reason that the sign in with X sign up flow is so popular!

Most of us app developers don’t use it for login, we use it to optimize Cost Per Install campaigns when we advertise on a Facebook property.

I'm really regretting including their SDK in my code, but I have too many users who have already logged in with FB to migrate away, and I can't take away that functionality since some people need to log back in/switch phones, etc.

>simply in order to have a slightly easier login flow?

Apparently you also need it if you want correct attribution for facebook ads, so the marketing dept might want it as well.

You answered your own question.

When the “business side” can claim a N% increase in conversion/daily usage/whatever having FB login, a developer will be tasked with implementing it uncritically, because if they speak up, they’ll be punished.

The “business side” doesn’t give a crap about privacy or performance or any of that stuff. They just see the numbers, especially their potential bonuses.

Late-stage capitalism, Baby.

I think this is pretty myopic. As someone who straddles both sides of this, the world is not that simple.

If the "business side" as you say isn't viable, then nothing matters. This has nothing to do with late stage capitalism...this is capitalism 101. If you're not hitting critical mass, you're dead.

This take also continuously misses that most people, and thus must customers, are willing to trade privacy/performance for convenience. If that's not your cuppa, then hopefully there's an alternative.

I never understood "Login with ..." from a user-perspective. I'm supposed to enter my facebook/google login-credentials on some random website?

How does the user know its legit?

That's the whole point of OAuth - you don't enter your credentials on "some random website", but you only have to enter your credentials on the identity provider's site. Frankly I trust Google and Facebook to keep my credentials secure a lot more than some random website.

But how do I, as a website-user, know who I'm telling my credentials?

You can check the address bar and TLS certificate.

I can do that as a professional. But even I don't trust popup-windows for google/facebook/mybank opened from another website.

I prefer to educate people to only enter credentials when they opened the website manually by themselves. That is also easier than trying to teach someone who can't distinguish between the address bar and the google-search field, what a domain and TLS is.

So maybe an app could send a request to Apple, then require you to open a new window and log in to the Apple site, navigate to an apps request page, find the right request, allow it, then go back to the original app. Or maybe copy a really long string and paste it, then copy the response and paste it back into the app. But you can see why no one did it this way right?

I mean, it is rather obvious if one has taken the time to go through such a flow (or even to just look at screenshots of how it works).

I wonder how easy it would be to spoof a "login with facebook" flow on a mobile app.

Can't be that hard.

On Apple though, your app might be taken down fast if you end up doing that. Doesn't mean you won't fool a few suckers though.

Reply on news.ycombinator.com