Rethinking Sign-In in the mobile first world

I have never been a fan of OAuth for signing in. Sure, it was better than sites asking for third party username and passwords, but It solved the problems for web-apps just around the time mobile was beginning to dominate how users interacted with the web. OAuth just does not work for mobile because the it was built on the premise that the sign in flow happened on a browser which could validate and enforce security.

As Twitter and Facebook started to get popular, sites started using their sign in buttons which were slightly better because on mobile, social login was handled by the OS. If you added your Twitter and Facebook credentials in the Settings on iOS, or had the appropriate Account Authenticator on Android, not only were you guaranteed security, the process was also a lot easier for the end user. That said, not everyone was okay with sharing their social data with these services, so the traditional sign in process on mobile remains the traditional links to use popular social platforms and an option for the more traditional email and password for those willing to endure some pain in exchange for some privacy.

As smart phones go global however, social login is just not as feasible. There are people out there without Facebook/Twitter accounts, or are getting more protective of their data. This trend has brought some interesting changes in the auth landscape.

Sign in with an email and no password

I recently read an article on how Medium is walking away from the whole passwords model altogether. Here is how they explain their system:

That’s right, no passwords. When you want to sign in to Medium, we’ll send you an email that contains a special sign in link. Clicking on that link will sign you in. That’s all there is to it. If you’ve ever used a “forgot password” feature, it works a lot like that, except you don’t have to forget a password to use it.

This is an interesting approach. On mobile this may be specially convenient where as soon as you get the email, you get a notification making the process fairly obvious without a lot of context switching between the site and the email app.

I recently saw this model implemented on Slack as well.

Slack is making this one of the ways to sign in, not the only way, which I think is smart. On a desktop I don’t mind typing a password, and might actually prefer that to switching to my email app/tab.

Sign in with your phone number

As the next phase of smart phone growth comes from developing countries, a lot of these people have never used emails. SMS is the communication medium of choice here, and it makes sense: SMS is the native mobile medium of communication.

The SMS model for auth asks the user to enter his phone number in the auth screen and then sends that number an SMS with an access code (or on Android with the right permissions, just detect when an SMS from them arrives on the device).

I first saw this model on WhatsApp, but has since been getting more popular. Recently Twitter has even released a service called Digits to enable signing in via SMS.

Sign in with another signed in device

One of the drawbacks of SMS based auth is that it cannot be used on devices that don’t have SMS capability (like Tablets or PCs). To handle this situation a lot of services are now implementing a way to log in on such a device by scanning a QR code on that device. The code refreshes periodically and when the app running on the mobile phone scans the QR code, the PC session and the mobile phone session are paired on the server and the user is signed in on the non-phone device.

Services like WhatsApp and Flipboard have started using this method, and I am sure more will follow.

A slight variant of this is the Apple Watch setup flow, which does the exact same thing but uses a different animated graphic that does the same thing as a QR code, i.e. pass data to another device using an image (click on the image below to go to the video)

Sign in with your signed in browser session

iOS 9 and Android M both include a more direct way to use the system browser rather than just using embedded WebKit / WebView. iOS’s new Safari View Controller and Android’s Chrome Custom Tab will allow app developers to use the browsers as part of their native apps. This will also let the native app get access to the browser’s Cookie store which means that users signed into the web version of the app can then be logged in immediately upon new app install. This detailed post by LaunchKit goes into details of that user experience.

Bonus: Sign in on app install (Google only):

While the previous paragraphs list a lot of alternatives to using social login if all you want is an identifying id, social login still represents the least friction way of getting more information and connections for a user. One thing I recently saw was Google’s “Android app install after sign in” feature. The system lets you add an “install app” step after a Google sign in on your site. The neat thing though is that the installed app is immediately signed in as soon as it gets installed. I recently installed an app that used this feature and it was great to not be prompted to log in on mobile.

This post summarizes a lot of new ideas I have been seeing lately around sign in lately. If there are any I may have missed, please leave a comment below 🙂

Bonus 2: Sign in with Google’s Smartlock (Google only):

Another system that was brought up is Google’s Smartlock that basically manages credentials across app and web sessions. I have very little knowledge about this but its worth being aware of. I think Netflix uses this.