Here are some tips on adding a second factor of authentication to your web application, with a smart user enrollment and communications flow to make the most out of this security process.
In the following scenarios, here’s how we define business and users:
- Business: The PSP entity that is looking to use Twilio Authy to perform SCA
- User: The end-user that needs to be authenticated by the business via SCA
Business setup with Twilio Authy
- The business developer user creates a customer account to start using Twilio Authy.
- The business then integrates the Authy API, specifically a User Status endpoint for the unlock method data and Push Auth endpoint. This “Getting Started” document is a great one to bookmark.
Enrolling a user into Twilio Authy security
- During the sign-up process, the business asks their user for a phone number and email address to be used for receiving Authy messages.
- The Business adds the User via the Authy API.
- The Business asks the User to install the Authy App; the user will receive an SMS download link from Authy. In some instances, users will already have downloaded the Authy app here.
- The business directs the user to enable the Unlock method for its Authy App. This is accomplished in the Authy iOS app by navigating to Settings > Security > App Protection: Enable > Protect Entire App. In Authy Android, users can navigate to Settings > Security > App Protection: Enable.
- The business confirms the user has enabled the unlock method by checking that enabled_unlock_methods is either “pin,” “faceid,” or “fingerprint.” Note that the action of a user enabling the unlock method does not set the “last_unlock_method” or “last_unlock_date” properties.
User authentication challenge to approve a transaction
- The business sends an Authy Push Authentication request to the user.
- The Push Auth request appears to the User as an app notification on the device on which the Authy App is installed.
- The user taps on the notification, which attempts to open the Authy App.
- To allow Authy to be opened, the user is requested to unlock the app with either their PIN, Face ID, or fingerprint.
- The user successfully unlocks the Authy App.
- The user sees the Push Auth request and accepts it.
- The business checks that Push Auth verification has been approved and records the updated_at timestamp of the approval.
- The business determines whether the last_unlock_method was “pin,” “faceid,” or “fingerprint,” and verifies that the last_unlock_date is within 5 minutes of the Push Auth approval. This data is available in the approval_request response. This check assumes that the transaction will be executed immediately after the Push Auth approval because the RTS specifies that the two authentication elements and the transaction should happen within five minutes of each other.
- If the last_unlock_date can not be verified as occurring within the five-minute window, then the business requests that the user close and re-open the Authy App (e.g., Go to phone’s home screen) to retrigger the unlock authentication.
Building better SCA-compliant security
Twilio’s Authy API can help payment providers meet dynamic linking requirements by making it simple to add 2FA to their services. But remember, when deciding how to implement SCA, consider the impact on the consumer. Get it wrong, and you’ll adversely impact customer purchase flow.
In addition to push authentication, Authy supports OTP delivered via SMS and voice, and TOTP generated in the free Authy app. Authy 2FA via an SDK is also available.
If you’d like to discuss your current authentication strategy and how Twilio can help, click here to talk to an expert.
- Download our e-book to review what financial organizations must know about PSD2 rules.
- Discover the critical user events in financial services that demand 2FA protection.
- Read our blog about the requirements of dynamic linking as it relates to PSD2 & SCA.