The Fall of Facebook Sign-in and the Rise of Passwordless.
How to implement SMS login with Flask and React-Native.
When we first built our app, we used Facebook Logins as a quick and easy way to create user accounts. However, given the recent Facebook scandals we have noticed a sharp decline in the percentage of ‘App Downloads’ that we were able to convert into ‘New Accounts’.
Simultaneously, there has been a shift towards passwordless logins, which allows users to authenticate with just an email or phone number. This offers the ultimate convenience for the user since they no longer have to remember any passwords.
With Passwordless connections seeing 6X growth in just 17 months, there is no question that Passwordless is steadily growing and will continue to do so. It is projected to overtake U/P usage as soon as late 2017 and no later than mid 2027, making it clear that the time to switch is now.
To test whether or not this has a big impact on conversions, we decided to whip up a quick endpoint that allows users to create an account and sign in with just their phone number.
Leveraging Twilio
Twilio’s Verify API makes the backend super simple to implement. We created two endpoints in our Python (Flask) backend: one to send the code and another to verify the code. If the verification is successful, we will either log the user in or create a new account.
Writing the Tests (with mocks)
We start off by writing tests to be test driven. Since we are using a 3rd party API, we’ll want to create mocks for our test. Mocks allow us to avoid actually sending text messages (which we can’t use anyway since it goes to a phone), while simulating the behavior of what Twilio would do.
Python’s standard “unittest” module comes with mocks included. All we need to do is “patch” the function we want to mock (in this case, “twilio_send_verification_code”) via a decorator.
Here, we show two tests. One to test for the case where the SMS is sent successfully and one for when the phone number is invalid. Of course, in order for your tests and mocks to be comprehensive, we need to look at Twilio’s docs and see what the potential responses are.
Implementing the endpoint
After creating the failing tests, we started making a wrapper function around the Twilio request to standardize the outputs. That way, if Twilio ever switches up the API, all the changes would be encapsulated in the wrapper. This is what sending the SMS code looks like:
And then all that is left is incorporating this into our own endpoint:
The Frontend
Now in the frontend, we create two screens. One for login and one for verifying their code.
The fields are fairly straight forward, however, we added some UX candy on the form for number formatting and error handling:
That’s about it! Overall this only took a few hours to implement. We just deployed it, so I’m still waiting to see if there is a noticeable difference in user signups, but I’m feeling optimistic!
If you want to check out the signup flow, you can download the app here: http://onelink.to/axle .
