1. Facebook Login (or other social logins)<p>2. Phone number with SMS code<p>3. Username/pass<p>4. Email/pass (Email will need to be verified)<p>Would like to hear people's opinions. Assuming the app doesn't absolutely need Facebook's social data, all the options seem viable with different pros/cons.
I think we're back to email/pass as a preference. Because folks are so wary of apps requesting permission to their social accounts or people no longer using said social network. There's definitely social fatigue in the air.
I would try to get away with the most minimal thing possible. Ideally I would do the same thing flash games have always done and create a cookie for the user.<p>If they need to login from a different place, I would put a simple 1 line form and button for emailing a link that would allow them to do that.<p>If it was necessary, I would give them the option to backup their account to an email address. This would just set the hash to something new so that the old cookie info no longer works, and they only have to click the reactivation email.<p>If this is an account where virtual goods are purchased (like Steam) and so there is actual value to the account, I would do email + phone backup. Phone backups aren't good enough on their own because people switch phone numbers. Emails aren't good enough on their own because people reuse login data all the time. This is the only case where I wouldn't store login data using cookies.<p>Forcing registrations and logins on the user really doesn't make sense 99% of the time.
In 2016 there are different levels of logged in:
L1 - I think I know who you are because you have a cookie or I remember your IP or browser fingerprint
L2 - I definitely know who you are because you logged in during this session and have a cookie
L3 - I trust you enough to show you your user info over https since I just asked you to log in and you gave a password or verified you with facebook.<p>Obviously some bigger names are experimenting and trust their tracking enough to do away with authentication for some things. Personally, I have an anonymous mode on one site. It is "I don't know who you are but I remember you." They can use the site and then convert to a real user with facebook, google, or email/password.
I already have 1000 different accounts on 1000 different websites. I don't want yet another one. Can someone fix that?<p>Fuck emails. Fuck passwords. I don't want to deal with any of these things. What's the purposed of being logged-in anyways?
I chose to do Facebook and email/password.<p>SMS costs a very tiny amount of money, and didn't offer any advantages (you can't get at the user's phone # on ios, so you cannot prefill, thus email had a similar level of friction from the user's perspective).
What will users get out of logging in?<p>Which is to say that the first options would be simply for the app to work without anyone having to log in. That's practical for some apps, and of course not for others. The larger point is that just as a login mechanism might not be necessary, if it is necessary the choice of mechanism should make sense given the nature of the app...don't use Twitter for a self-help app for narcissism or Instagram for a seniors lifestyle app.<p>As for the alternatives, what good could possibly come out of storing name/email and password pairs?
I built a mobile web app, and I started out with just Facebook and Twitter login. However, I have some friends who are privacy conscious and they do not have social media. They would prefer to have a email/pass login option.<p>So that that is next on my list to add to this current project.
Really it depends on the app, but for the most part I like to give options for 1, 3, and 4. Social login is linked to an actual account that can be used for 3/4 if they want.