Verify Push is designed for global, web-scale use. The Twilio Verify platform that it's built on verifies over 200 million users annually. To fully realize the benefits of Verify Push in your own real-world production implementation, we've compiled a running list of best practices to consider. These best practices are organized as questions/answers or suggestions under topics, like Conversion Rate, Security, Performance, and Project Management.
A critical step in the Verify Push verification sequence is for the app on the registered device and the user to be made aware that a pending challenge has been created by the customer backend/Verify Push API. The basic method for achieving this is through the Verify Push API (technically Notify) sending a visible push notification to the app. However, this method might fail in certain scenarios like poor connectivity, the app being in a closed state, or users turning off push notifications. For production use, we suggest implementing additional methods to robustly handle all scenarios:
- Configure app to receive push notifications, including background notifications that can still be received by the app even if the user has disabled visible push notifications.
- If the app is closed when it receives the push notification, it should attempt to store the challenge_sid and factor_sid contained in the push notification's payload, so that it can immediately poll the Verify Push API with that data when it’s next opened.
- The app should poll for pending challenges whenever it’s opened, in case it wasn’t able to receive/store a push notification that was sent when it was closed.
- Tell the user to open the app on the registered device to view the push approval, in case they didn't see a visible push notification.
- Give the user the option to request another push if they didn't get the first one. This can be done by creating a new challenge. The app should have logic to de-duplicate challenges that are approving the same action (don’t show the same approval twice). For example, the app can check in the customer backend if the challenge is still valid for the action to be approved. The customer backend can store the challenge_sid after creating it.
- Offer the user fall-back verification options if available.
In addition to the basic methods, consider these additional ones:
- Nudge the user to enable visible push notifications after they register their device, so that they will see a push notification on the lock screen of their device.
- Have the app send a confirmation to the customer backend when it receives a push notification from Verify Push (Notify). If the customer backend doesn’t receive a confirmation from the app after an expected latency from when the challenge was created, then the customer backend should assume that the push notification failed and create a new challenge.
- Customer backend should subscribe to debugger webhooks for the Verify Service. These webhooks contain error codes published by Verify Push, including errors related to push notification failures.
- Display a button in the app for the user to “check pending push approval requests”. When the user taps the button, the app polls for a list of pending challenges and displays them.
Unlike SMS, which has country-specific constraints due to Carriers being country-specific, Verify Push works whenever there’s an internet/data connection and on any device that runs standard iOS, Android, or a supported web browser. The exceptions to this that we are aware of are:
- Android devices built by Huawei that don’t support Google Messaging Services, including Firebase Cloud Messaging, won’t be able to receive push notifications. However there are workarounds to this as explained in “what are methods to ensure that the device receives the challenge?”
- Country prohibitions defined in Twilio’s general export control policy (e.g. Iran)
1. If a user installs the app on their device, registers the device, deletes the app, and then reinstalls it on the same device, will the device become registered again?
No, deleting the app from the device completely unregisters the device from Verify Push.
From a technical perspective, a user can register multiple devices as factors. From a security policy perspective, the decision of whether to allow a user to enroll more than one device as a factor is up to you. The benefit of doing so is that it makes it more convenient for the user to respond to a push from multiple devices and it creates redundancy if they were to lose one device. The downside is that it increases the attack surface for a fraudster. Note that querying the SDK on an enrolled device will only return the factor(s) created on the same device, so a fraudster wouldn’t be able to discover all of a user’s registered device.
You can configure Verify Push such that the user can receive/approve a push in the app on the registered device, even if they aren’t logged into their account on that app. Conversely, you can require that they login first (using a different verification) before approving the push.
The overall Verify API SLA for the latency of responses to requests is 300ms. This is measuring the time from when the request is received by the Verify API to when it sends the response. A different latency measure is the round-trip-time (RTT) latency, which is measured from when the request is sent by the requester to when the requester receives the response from the Verify API. RTT latency will be longer than the responses-to-requests latency, and will vary depending on the physical distance of the requester to Verify API’s servers, which are located in the US East Coast by default. If you want to reduce RTT latency, try two things:
- Try to reduce the overall number of requests you’re making to the Verify API. While this won’t reduce the RTT of an individual request, it will reduce the overall latency experienced by your users. One example optimization: when you’re registering a new user and device, you don’t need to make a separate Create Entity call, because the Create Factor call will both create an Entity and a Factor at the same time.
- Send your requests to a public Edge Location that is physically closer to where you’re requesting from compared to the default US East Coast location. While Verify API does not fully support Edge Locations currently, RTT latency can still be lowered, because the shared Twilio API gateway services that Verify uses supports Edge Locations. Note that using Edge Locations might actually increase latencies when reusing connections, and so you’ll need to try and see if this is acceptable. You can switch to an Edge Location by changing the request URL. For example, to send to the Singapore edge, the request AccessTokens URL should be:
Your mileage may vary. We’ve consistently heard that understanding Verify Push is the easy part. The complexity level of your existing apps/backend (e.g. how many places in your UX do you need to insert Verify Push?) is the major driver of the overall amount of work. As general guidance, we suggest budgeting the following amount of time based on feedback from customers who’ve done it:
- Setting up the Verify Push Sample App/Backend and understanding how Verify Push works in general takes 1-3 days.
- Integrating Verify Push as a prototype into your own app(s), backend, and existing login flows takes 1-2 weeks.
- Getting to production-grade, including testing, could take an additional couple weeks.
誰しもが一度は考える「コーディングって難しい」。そんな時は、お問い合わせフォームから質問してください。 または、Stack Overflow でTwilioタグのついた情報から欲しいものを探してみましょう。