Signing in to your mobile apps should be easier in my opinion than having to type a username and password. In my case it tends to be especially painful since I usually use KeePass to generate my passwords as random strings. Typing these long and random passwords on a touch device sucks. I’d like to see more alternatives when it comes to authenticating that are easier to use.

These are some ideas I’d like to see used more often.

The Sign-In Link

Slack uses a great method to authenticate mobile users. They get you to type your team name and your email address. After which you can use a “magic sign-in link” that signs you in automagically. The way it works is that they send you a link to your email, when pressed it signs you into your slack account. So no password required, instead proving that you have access to your email account is enough to log you in.

(I took the above image from https://auth0.com/blog/2015/12/04/how-to-implement-slack-like-login-on-ios-with-auth0/)

I really like this idea. I would love it if the HBO app had such a system, because it seems to have a knack for forgetting that I was logged in whenever I want to watch Game of Thrones. Especially for apps where users don’t really interact with billing and paying for stuff, I can see that such a scheme would be nice to use.

Access to your email already meant access to most of your accounts. Only select few sites enable some sort of two factor authentication that don’t just allow a potential hacker to reset your password via a “forgot password” function.

It also means one less password to remember. One less password that is potential reused, and then later hacked.

It does mean reliance on email infrastructure though. Which is already not so secure, depending on who your provider is. Spoofing and phishing is probably still going to be a problem for email a long time into the future. These could probably also be used against this type of scheme.

A protocol of such an authentication scheme might look as follows:

1. Mobile App Requests Sign In from server, providing email address.
2. Server sends an email with random token embedded in link, unique to email address.
3. User presses link in the email. Link opens server webpage which in the backend sends a token to the mobile app.
4. Mobile app receives fresh authentication token and uses it for future authentication.
5. Server keeps track of active tokens in case they need to be revoked.

Of course, this is very similar to other authentication schemes where you rely on a third party to verify your identity. Other popular choices are to use Facebook, Google or other website logins that you have already authenticated for the device. However Facebook and Google both have privacy concerns (as large companies selling your data for adverts) as to why you may not want to allow them to determine your authentication. They will likely track the application you used.

But other transports could be interesting too. For example, you could authenticate over SMS if it’s a phone device. This would require a phone number instead of an email address. It would also incur a cost on your business to, since you have to send out the SMS.

Key-Exchange over Local Network

In general I’d like to see more apps that communicate locally. That is my computer to my phone, or vice versa. An app I’d like to code when I get the time is a basic notifier to forward alerts from my PC to my phone, for example. However, I’d like it if the applications did not always rely on a backend server on the Internet. When I’m in my home and I share a local network, it seems very unnecessary and sometimes unsecure to have to route my messages between my devices via a server on the internet.

Instead I would like to see a protocol which implements a Key-Exchange over the local network instead. This way you can set up a secret key for devices to communicate via, so long as you trust your local network.

I think one way for this would be to communicate via UDP. One client broadcasts on UDP for the other to search for it. Once they find each other, they perform a key-exchange like diffie-hellman, and finally ask the user to verify the connection by showing the fingerprint. This is probably very similar to how bluetooth is done, but over an IP network instead.

Once the secret keys have been set up, your devices can then safely communicate end-to-end encrypted over the Internet.

Verification via QR-code

Continuing on devices that communicate locally, another way of exchanging a set of keys could be to use QR codes. This could done by outright sharing a secret key by showing it as a QR code for the another device to scan via camera. Or in the case of authenticating to a third party service, it could contain a token or signature which the new device could use to forward proof that the user already has access.

Obvious advantage here is that the exchange can be done offline. It does however require a camera for at least one of the devices. For a key-exchange the key may also have to fit in a QR code.

For a token based system, where two devices connect to the same api. You could allow an authenticated device help a second device authenticate the following way using a QR code.

1. Authenticated device generates token. Sends token to backend server to save. Shows token in QR code.
2. Unauthenticated device scans token. Uses it to authenticate with backend server.