6 ms·
Are we beyond using email as a login method?
So I'm creating a new application and wondering if it's necessary for me to include an option to login via email (and password) versus only providing the ability to login with Facebook/Google/Twitter/etc.
Pure email accounts are a hassle for me (the developer) because I need to manage passwords, verify emails and support forgot password flows.
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't remember the right one.
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.
Essentially I want to balance friction at login (as well as onboarding) while also alleviating any technical complexity I don't have to do by leveraging these social login methods (exclusively).
Are we beyond using email or should I still support it?
[1] https://janrain.cloud-papers.com/content/62/2013-consumer-research-value-social-login
- necovek 8y agoIn 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 7y agoI 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.
- smt88 8y agoAbsolutely 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.
- tjkrusinski 8y agoYou can also go password-less. Sessions are started with a URL sent to email. The session only begins if the cookie + signed URL match.
- halfmatthalfcat 7y agoI reallllly wanted to do this in the beginning because it's so simple. However I think I came to the conclusion that forcing people to go in and out of their mail client every time they wanted to login was too much of a barrier, however I'd be easily convinced if people thought it was a better and more viable way to handle login.
- stephenr 7y agoThis 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 7y agoDebunked 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 7y agoYou 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
- kevinsimper 7y agoIt would be a good idea, most websites you don't need a password to login anyway, you just need to uze the password-reset form each time!
- 5555624 8y agoWho 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 7y agoMy 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).
- mairaulau 8y agoNo. Not yet. I know people like my mom (50+) rarely don't have social media channels to use instead. But if your target audience is under 50 then go for it.
- thoughtpalette 7y agoit would be the end of the world
- codingdave 7y ago> 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 7y agoAgreed, 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.
- chatmasta 7y agoUse 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 7y agoConsidering this as well. Doesn't mean I never have to do it.
- stephenr 7y agoSo 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 7y agoNever 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.
- deleted 7y ago[deleted]
- return1 7y agoBrowsers 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
- codegeek 7y agoThis 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.