Emoji based authentication
Authentication can be described as a game of tradeoffs, sometimes the level of authenticity of the user isn’t actually that critical and some times you need to provide multiple factors for authenticity. I’d like to propose an authentication scheme for the former.
The problem comes about when you’re building a consumer facing app where you want to optimise for ease of use and efficiency of signups over being absolutely positively sure that the person using the app isn’t trying to defraud you. But even if they are, you can add that second level of authentication later.
Currently, you might solve this by verifying an email after signup, or sending an SMS with a 6 digit verification code, while blocking access to the app until the user enters that code.
The problem with these approaches is that you need to ask more information than you might need (in the case of email) and require more user interactions which increase friction and reduce conversions in the case of remembering and retyping a 6 digit code.
On-boarding flow
The idea here is that we will send an emoji to the user, then ask them which one they received. Simple.
The obvious flow for this is:
Walking through these screens, firstly we ask for a phone number which we’ll tie to the account on the back-end.
Secondly we’ll send an SMS to the that number containing a randomly selected emoji, and tell the app which emoji we sent. The purpose of this is to verify that the user who entered the number is also using that phone.
Thirdly, when they select an emoji from the list, we’ll hash that emoji + their number and send that to the server to exchange for a bearer token, similar to how the OAuth 2 Resource Owner Grant Flow works.
That’s really all there is to it. It’s not the most secure flow possible, but it might solve a legitimate problem where you don’t really care because you’re not handling anything super secret or valuable. If you are doing something secret or valuable, maybe don’t do this.
A not so obvious thing about this flow is that if you never collect any other identifying information, your users won’t be able to recover their account if they ever lose that number, so if you transact something, you might want to collect an email or something else unique when the time is right.
What about passwords?
The last point to make is that you don’t need to set a password, this is really a bug and feature sort of scenario. When a user returns to your app, instead of signing in with their username and password, or phone number and password, simply repeat the flow above. This also reduces the work you need to do in your app because you only need to build those 3 screens.
What about security?
I highly recommend that you read about security before building anything relating to authentication, authorisation, or crypto. If you don’t, you will eventually do something stupid and get owned. If in doubt, use something which has been tried and tested by others.
Wait, so this whole idea is pointless? No. It’s a solid and simple on-boarding flow which should work nicely. Just be sure you understand the tradeoffs.
Conclusion
On boarding is a tricky game of being efficient in asking for information, while reducing friction and maintaining the right level of usefulness of your app. You often don’t need more than one piece of identifying information to get someone started, and when you do, that is when you should ask for it.
Emoji based authentication is simple, recognisable, and provides a low level of friction to the user at a level of tradeoff which can be accepted in many scenarios.
If you end up building this, please let me know, I’d love to know how it works. Tweet at @ivanderbyl.
