An increasing number of apps now have two-factor authentication implemented whether it’s an email or SMS authentication code for user registration. The added layer of security helps to prove a user’s authenticity and identity, decreasing the chance of fake users trying to exploit them. But how to proceed it for mobile app testing? when should regression tests be able to continuously click through the registration process without user intervention?
There are few tried and tested workarounds to implement two-factor authentication to be a part of mobile test automation. In this blog, we’ll take a look of the most common one and how it can help testers and developers to overcome with authentication issues.
A generic two-factor registration process consists of three distinct steps:
- The users enter his or her information and phone number and/or email address to the app
- The app’s backend sends an authentication code via SMS or email
- The user reads and enters the code to the app
Entering user information using test automation is a relatively trivial task, but in the second step, problems arise. Most apps do not have an integrated SMS or email app, so reading the authentication code would mean navigating to a different app on the mobile phone. Adding functionality for navigating different apps to read authentication codes should be avoided at all costs because it would add unwanted dependencies and failure points. What alternatives are there for reading the codes, without unnecessary code overhead?
Two-Factor Authentication with SMS APIs
Numerous online SMS services such as Twilio offer to send and receiving SMS messages using virtual numbers, allowing SMS access through clean REST APIs over the internet.
Many of these services, for obvious reasons, focus on outgoing messages and allow incoming messages only to be rerouted as an HTTP request to any given address. Without any cloud-based storage of messages, using these services would require setting up a dedicated web server for receiving and saving the messages, so they could be retrieved by the test executing on the phone later. In some cases this might be a valid solution, but setting up new hardware and maintaining it always costs money.
Another problem with online SMS services in our case of authentication is the nature of virtual numbers. Messages between virtual numbers are usually blocked by providers for security reasons. As most authentication code SMS messages are sent by these online services (using virtual numbers), receiving the messages to virtual numbers is not possible. Sometimes the blocks can be disabled for example for development environments, but generally, another approach is needed.
Virtual numbers backed by real SIM cards
To overcome the block of virtual to virtual messaging, a virtual phone number that appears to be a regular number is required. Fortunately there are services which provide an online number that is tied to a real SIM card’s number. One of these services is Google Voice, which allows SMS messages to be received directly to the user’s Gmail account.
To enable a Google Voice number, the account needs to be activated with a real phone number. However, after activation, all messages to the Google Voice number can be read directly from the Gmail account without a real phone or a SIM card. Furthermore, the Google Voice number is not considered to be a virtual number by other services, so receiving authentication messages should not be blocked!
Authentication at Test Runtime
Using the tools discussed above full two-factor authentication can be achieved fully in test runtime using only the test’s code. A lightweight POP3 or an IMAP client can be easily integrated into the test framework, and when it’s time to receive the SMS or email authentication code it can be read directly from the Gmail account with no extra hardware and very little code overhead.
In addition, there are alternative two-factor authentication methods that can be used as part of the mobile app testing and test automation. Get in touch if you like to know more about those!