
Are we beyond using email as a login method? - halfmatthalfcat
So I&#x27;m creating a new application and wondering if it&#x27;s necessary for me to include an option to login via email (and password) versus only providing the ability to login with Facebook&#x2F;Google&#x2F;Twitter&#x2F;etc.<p>Pure email accounts are a hassle for me (the developer) because I need to manage passwords, verify emails and support forgot password flows.<p>Email accounts also seem to be a hassle for the common layperson because they (1) are at risk of forgetting the password and having to go through the forgot password flow themselves or (2) having to try a couple passwords and wasting time at the login prompt because they don&#x27;t remember the right one.<p>I&#x27;ve tried to find some research on the value of social logins[1] but it&#x27;s a bit slim on user attitudes and their preferences.<p>Essentially I want to balance friction at login (as well as onboarding) while also alleviating any technical complexity I don&#x27;t have to do by leveraging these social login methods (exclusively).<p>Are we beyond using email or should I still support it?<p>[1] https:&#x2F;&#x2F;janrain.cloud-papers.com&#x2F;content&#x2F;62&#x2F;2013-consumer-research-value-social-login
======
stephenr
So two things:

As a user, I won’t ever use whatever you’re offering if it’s only got social
login.

As a developer: if storing passwords, sending emails and accepting
confirmation clicks is considered “too hard”, I hate to imagine how the rest
of your app works.

~~~
halfmatthalfcat
Never said "too hard", just said introduces unwanted complexity in the
beginning if I can avoid it. If my users don't care, then I don't care tbh.

------
necovek
In general: nope. Privacy and tracking concerns, exclusion of users not on
your choice of login services...

Otherwise: depends on your target audience. I.e. are you building a google
analytics add-on? Asking for a google account sounds reasonable.

It's up to you to decide on the trade-offs.

I personally won't be signing up except maybe with a burner account to see
what the fuss is about (if you get that much chatter going around), but I
won't be using (more importantly paying for) it ;)

~~~
halfmatthalfcat
I see and agree with the privacy concerns however I'm trying to judge whether
my target demo values ease-of-use over friction that comes from managing
passwords.

The demo I'm looking at is quite broad so I'm trying to plan for the lowest
common denominator...questioning my early adopters is definitely part of the
plan but I'm trying to pre-empt some potential technical complexity in the
beginning.

------
tjkrusinski
You can also go password-less. Sessions are started with a URL sent to email.
The session only begins if the cookie + signed URL match.

~~~
stephenr
This is a ridiculously bad idea that’s been debunked as insecure and worse for
usability dozens of times.

Requiring a webcam and signing in by recognising interpretive dance would be a
less crap idea.

~~~
flashm
Debunked how? It seems the consensus is that it’s just as secure as using a
username and password and allowing the user to reset via email. It’s been
discussed here a few times.

~~~
stephenr
You have zero control over how their email is handled - and you're providing a
way to login, no questions asked, with just access to their email.

The usual "argument" about email resets is irrelevant - a password reset (a)
doesn't have to be fully automated, (b) doesn't grant invisible access to an
attacker (c) should leave an obvious audit trail

------
5555624
Who is your target audience? Are they likely to have a
Facebook/Google/Twitter/etc. account? Are they likely to log in with it?

More and more people don't have Facebook or have stopped using it; so, you
shouldn't go with just Facebook. The subset that don't have one of the three
you used is smaller; so, are you willing to risk users who don't have or don't
use them?

Personally, while I have Google account, I do not have a Facebook account;
but, I don't log in with it anywhere, other than Gmail.

~~~
halfmatthalfcat
My target audience is quite broad and from what I can gather (just by
evaluating the communities themselves, not directly engaging individual users)
they _most likely_ have social accounts and (in my opinion) will be willing to
log in with social versus email/password.

I think I'm looking more for a "pulse" of where things lie in terms of how the
hypothetical average user feels now. Querying Hacker News is probably not the
best place to ask (since most of us are engineers or of the technical ilk) but
I'm trying to get as many opinions as possible.

However like other people have commented, I need to directly engage the users
(who don't exactly exist yet since I'm still building the MVP).

------
codegeek
This questions comes up a lot. It really comes down to your specific Product
and the nature of your users. Are you selling a Social product that ideally
talks to Google/FB/Twitter anyway ? Sure, go ahead and provide Social Logins.
Are you selling a B2B SAAS that has nothing to do with Social stuff ? I am not
comfortable giving you access to my Google/FB/Twitter then. I don't care about
OAUth and stuff.

Also, whats the big deal these days implementing a basic email/password based
login. All the popular backend languages (PHP, Node, Golang, Ruby etc) have
libraries or frameworks that provide email/username auth out of the box. One
example: Laravel in PHP. You literally do "php artisan make:auth" and it sets
up the scaffolding for login, registration, forgot password pages and of
course uses bcrypt to hash passwords. I am sure other frameworks have similar
options.

So this is a not one size fits all type of answer. You have to look at your
users, their preferences and the use cases. But if in doubt, just implement a
basic email/username auth. It never hurts and I would argue is not that big of
a deal these days to implement due to the frameworks that are available.

------
smt88
Absolutely not. Lots of people don't have social media or won't trust you with
it.

Security/authentication/authorication is a hassle. If it's not, you're doing
something wrong. Even plugins like Janrain require extra work that can be
tedious.

------
codingdave
> I've tried to find some research on the value of social logins[1] but it's a
> bit slim on user attitudes and their preferences.

You need to ask your own users, not HN or the general public. (Unless HN is
your target audience). Each community may have different opinions on these
kinds of questions, and like any product development, you need to directly
talk to the people who will buy your product about details of how it is built.

~~~
halfmatthalfcat
Agreed, I think I'm somewhat putting the cart before the horse but I'm in
development so it's a question I'm asking myself now before the MVP is
finished.

------
return1
Browsers make it easy to remember logins/passwords across devices. Also,
privacy concerns and the possibility that they might even be closed one day
make one wonder if you should include social login at all. Those were useful
during fb’s growth phase where they would bring a lot of trafy. Nowadays those
channels arr all but dead

------
chatmasta
Use whatever gets you to launch faster. That probably means integrating with
only third party services so you do not need to worry about registration and
forgot password flows. You can always add email authentication later.

~~~
halfmatthalfcat
Considering this as well. Doesn't mean I never have to do it.

------
thoughtpalette
it would be the end of the world

