Social login vs traditional email/password?

I personally dislike sites that offer multiple types of social logins. I never remember which one I used. If you pick a 3rd party, stick to a single one

I never trust sites that ask for a password, in 2020 I expect to see federated login, and it is huge mark against the site that doesn't have it. Passwords are an antiquated insecure option that takes a lot to get them right and very little to get them wrong. Not to mention it forces me to continue paying for a password manager. (We run an app security plug in for services, think authN/authZ, and this is the recommendation we give to our customers/partenrs.)

Unless there is a really good reason to have passwords, avoid it.

It depends on your target audience. Most of the time having both lowers the entry barrier, I believe.

This is my experience with my web app Watermark.ink Online photo watermarking tool.

Other than email I had other social login mechanism Google/Facebook/Twitter. Now I removed twitter, I want to remove facebook too but there are few users who already using it.

Percentage of users by login mechanism

email: > 90%
google login : ~4 %
facebook login ~2%
twitter < 1%

There is a zero chance of my product breaking the user privacy rules, because I only use user email (nothing else). I never sent a single subscription email or contacted any of my customers with emails like new features, offers etc. .. not a single email from me to customers. But still twitter gives me shit.

I almost made a twitter blog reminder app and dropped it completely because twitter killed it with restrictions. It was a simple app to send reminder tweets when its time to blog. Wasted domain : timeto.blog

I don't consider facebook and twitter logins for my future apps, its not worth the effort and maintenance. Even if you do, think of them at later point of time.

86% of users report being bothered by having to create new accounts on websites
77% of users believe social login is a good registration solution…
92% of users will leave a site instead of resetting or recovering login info
88% of users admit to entering incomplete or incorrect data on registration forms

Sep 2, 2019
https://cxl.com/blog/social-login/

One should offer both if possible. And permissions for social login should be minimal and specific permissions should be required only to specific actions. I would never log to a website which would want access to my contacts, posts, rights to post for me, etc. at the beginning.

At OrgPad, we offer both. Out of 960 people currently registered, only 290 people registered via email, 568 via Google and 113 via Facebook. But we originally only had registration via email for first 150 or 200 people, so let's say 100 since then registered by email. So the ratio is like 1:7.

Login via social networks makes things much easier. It requires just two click to have an account created and people don't have to remember password or fill in anything. Some people likely use email since they don't want to share their personal information, or are actually unsure what login via social network means (I was one of these people, before I coded OrgPad). At OrgPad, our policy is that users have full control over all their information, we just ask for basic credentials (name, profile photo, email) and these are inserted into their created public profile. But the users can easily remove any of these information when they don't want to share them.

I’m actually thinking about switching entirely to the magic link

As a developer, I think using an OAuth provider is a big win. It allows you to do away with secure password storage, password recovery emails, two-factor authentication logic, and other authentication boilerplate. Arguably, it's a form of expensive technical debt as, at some later stage, you'll likely want to own authentication end-to-end.

As a user, I can't always remember which OAuth provider I used to login (doh!) Then I end up creating a new account, and OMG! It's such a mess.

Also as a user, sometimes the OAuth provider is a natural choice. I am thinking of Code Sandbox where it's natural to login with GitHub and, in turn, allow Code Sandbox access to my GitHub account to create repositories, commit changes, and so on.

My philosophy?

Offer an OAuth provider if it's a natural choice. It's alluring to think "social login reduces friction, resulting in an increased page conversion rate". And it might, a little. But what you really care about is the broader funnel - acquiring users who activate and eventually convert. If a customer has intent, creating an account will be no trouble for them. After all, have you ever rejected a promising app or service because you got to the create an account page had to write username and password?

If you're gonna have one login only, it should be email/password, since that's the only one everyone is guaranteed to have. Your second login option can be some social.

But you're building an MVP and you no have business having more than one login option.

Therefore email/password is the right answer.

I actually like email + sending a magic link to log in, like Slack does. You get the benefits of capturing emails while making it easy for people, while also supporting SAML should you need it for enterprise.

There is another legit option for the auth - email password. Users will enter the email address and get a code or link with code that would signup/signin.

It's a very simple approach that doesn't user require to either remember something or reveal too much of themselves with social media. Of course it's a bit more hassle to wait for the email which might sometimes end in spam folder (good setup of mail service prevents that). It's kinda bad if you want the auth session to expire often. Nobody would like to go through that every day.

I think that it is a personal choise, someones prefer to sign in with the mail process, others with the fast social sign in. Give the choise to the use can be a good solution for everyone!

I use Auth0 for all my projects. That way, I can pick Social or whatever I want, and there is barely any setup.

Social Login. Specifically Google login for me. But I am picky in choosing the services. If a company offers only a email+password signup then the value proposition must be on point if it's an ad pitch or it should be something I am already searching for to solve a very painful problem.

Usually it's email, sometimes GitHub login. However, lately I'm using to Apple's new signup service whenever available.

Depends on the product audience but no matter what I'd also implement a email/password login so that people who only want to try it out would be able to do so without giving "access" to their personal info such as email, real name, etc. I'd add social login as a complementary nice to have thing rather than considering it central to the user system.

For B2C, I'd opt for facebook and twitter
For B2B I'd opt for Google (a lot of companies use G-Suite), if it's a tech company i'd also opt for Atlassian, Gitlab and/or Github.
For B2B but not tech, I'd opt for Linkedin although I never saw a website offering Linkedin social login.

I think using auth0 was the biggest waste of time when building my site.
Login / sessions-authentication are so central to everything in your app, and using auth0 just felt like a very sideways way of making it. It did not really help with session management. They also had no bulk user management features, which I needed to clean up spam subscribers.

I would love to know if adding some social login options would help my conversion. Im thinking github/google for my sass.

As a user of 1password I personally prefer to use username/password login.

In order to analyse the user base I prefer to use the traditional email&password option:

• With email you can usually guess the company by looking at the extension.
• When you allow Social login you need to add each social media to the referral exclusion list in Google analytics, which can be tricky with some social media (for instance Facebook).
• Also in early stage the fact that people make the effort of creating logins is an interesting signal.

Social login makes sense if you user base overlap with the social media: for example offering github login for a dev tool.

From a developer standpoint I prefer the traditional approach as it's easier and typically offered out of the box in most frameworks.

From a business perspective:
Users whether important or not usually don't like filling out forms especially to a new website they don't yet know and ironically feel they have more security by using a login from a 3rd party they already know (ex: Facebook, Apple)

The more informed users however would create a an account via traditional means.

Speaking for myself as a user I use both, depends on if it's for work or personal use.

We're using Auth 0 for a project I am working on right now and it's super slick. Allows you to spin up both social and manual account creation easily. For our project (which is a mobile gaming platform) we're finding that the majority by far are using their Gmail account SSO.

damn this thread has given me some great ideas to test out to really simplify login!

btw, apparently when you use google auth on phone apps, you have to have apple login aswell. What's up with that?

cool topic! we're experimenting with "magic links" and passwordless: https://www.indiehackers.com/product/yen/keeping-the-bar-high-passwordless-entry--MFbKtELSfswwezBGxpY

this is better than both... :P

Auth0 let's you use a verification code that is either emailed to you or sent as SMS. That allows you to not need a password and not need to use social login. Seems like a pretty good option.

(although I personally find this method more cumbersome than simple password)

Are you building an app or just a website? I wrote a blog about our journey here: https://snaphabit.app/blog/password-less-login/

The tl,dr is Apple Login may change your decision.

It all depends on your audience, in my case I developed a product (upstamps.com) for developers so I chose to use Github and traditional email / password.

I think it is always important to have the traditional and choose the most relevant social ones for your product. Ultimately, you always have an email / password.

So it highly depends on what your product is and who your target audience is. We support specific SSO logins because customers told us they value it - it also massively improved the trust, confidence and easy of use for them.

For me, yes it's laziness for email/password, but it is also a chore for the development team too. Our users always seem to signup, but we are picky for the social logins, we only use the ones we think our users want. It doesn't make sense to add Facebook to a B2B product for instance.