Best practices for implementing Silent Network Authentication in production

Best practices for implementing Silent Network Authentication in production

Silent Network Authentication (SNA) allows your business to seamlessly and securely verify users behind the scenes without any user input. This is an excellent solution for reducing friction while maintaining a strong level of security in your verification or authentication flows. Learn more about how SNA works behind the scenes here.

This blog post will dive into how to handle implementation details, manage edge cases, and scale the solution globally.

Prerequisites for building with SNA

Before you can start scaling, you need to do the following:

1. Complete the carrier registration form to start the 2-4 week approval process.
2. Create a Verification Service in the Twilio Console
3. Start a new verification with SNA

After you complete those three steps, the rest of this document will help you manage situations outside the common happy path.

Force mobile data for SNA inside your mobile app

Because SNA relies on cellular network authentication, invoking the sna.url must be done on mobile data, not WiFi. The API will throw Error 60531 if you try to request the sna.url on WiFi. You can force this in your mobile app.

For iOS, use the iOS library* to force mobile data for the request. The library also provides custom errors, network validations, and multi-threading support. If necessary, you can also reference this Objective C function code on GitHub (here's an example of calling that code from Swift).

For Android use the Android library* or reference the following sample code using requestNetwork to force mobile data for the request:

*reach out to request access, open source access expected in 2023.

Follow redirects

When you invoke the sna.url, the documentation tells you to follow all redirects. The reason for this is that each carrier has slightly different redirect handling, so we built our API to obfuscate the differences so you experience consistent behavior with one interface.

You can find the redirect URL in the location header of the sna.url invocation response.

In pseudo code this would look like:

Note that some carriers can have multiple redirects. You can trigger the Verification Check after the redirects are complete.

Use edge locations in certain regions

Regulators in EMEA require that all data remain within the region. Therefore, Twilio has separate API URLs for edge locations. As we expand to new regions, this list of data resident regions may grow.

Learn more about Twilio Regions in the documentation or contact us for regional implementation in India and Indonesia.

Handle dual SIM

Phones in certain countries like Brazil, India, and the Philippines often have multiple SIM card slots. There are two typical reasons why users take advantage of this. The solution for both scenarios is the same.

Scenario 1: Users rotate secondary data SIM

Users choose one mobile operator SIM for their voice calls. This phone number is associated with the user’s identity and is the number they give to friends and family. This SIM is in slot #1.

For slot #2, the user chooses the data plan with the lowest price. The user may change this data SIM often when there are new promotions. The user never knows the phone number associated with the phone number in slot #2.

The issue in this scenario is that Silent Network Auth uses the data network to authenticate the active phone number (possibly from slot #2), while the user has provided the phone number associated with their identity, which may be the phone number from the SIM in slot #1.

Scenario 2: Users rotate primary phone number SIM

Similarly to Option 1, some mobile operators offer promotions where calls to phone numbers on their network are free, so the user may maintain voice SIMs from multiple MNOs and give out the corresponding phone number to friends and family on the same network. The user knows all of the phone numbers associated with their SIMs.

The issue in this scenario is that the user could sign up with any one of their phone numbers and it is possible that it is not the one associated with the active data network.

Solution: for both scenarios, our solution is to get the service provider from the user-provided phone number and compare that against the service provider from the IP address of the data SIM. If the service providers do not match, then we confirm a dual SIM and send one of the following errors back to your application:

• Error 60500 - SNA Phone Number Mismatch
• Error 60532 - SNA Potential Dual SIM Detected

Deal with out of coverage and fallback to other channels

While some scenarios have fallback options to make SNA work, all have the option of falling back to other channels offered by the Verify API like WhatsApp or SMS.

These are the most likely situations where SNA may not work.

1. The user is on a desktop device

Because desktops do not use mobile data, either fallback to another channel or follow the instructions here to direct a user to a mobile device from the desktop via a QR code or by sending the user a link in an SMS.

2. The user is on Wi-Fi in a mobile browser

Ask the user to turn off Wi-Fi or fallback to another channel. You will likely see Error 60531 in this case.

3. The user's cellular network is not covered by SNA

Fallback to another channel.

SNA FAQ

For more answers about things like error handling, geographic coverage, latency and more, visit the SNA FAQ in the documentation.

Other considerations for SNA

Silent Network Auth is a great frictionless authentication solution for your application. We also recommend adding fallback options to other channels

For further reading we recommend:

• What is Silent Network Authentication?
• Silent Network Auth Technical Overview

If your question wasn't answered by this document, please get in touch. We can't wait to see what you build!