• About
• Dependencies
• Requirements
• Documentation
• Installation
• Usage
• Running the Sample app
• Running the sample backend
• Using the sample app
• Logging
• Errors
• Update factor's push token
• Delete a factor
• Clear local storage
• Contributing
• License

Twilio Verify Push SDK helps you verify users by adding a low-friction, secure, cost-effective, "push verification" factor into your own mobile application. This fully managed API service allows you to seamlessly verify users in-app via a secure channel, without the risks, hassles or costs of One-Time Passcodes (OTPs). This project provides an SDK to implement Verify Push for your Android app.

None

• Android Studio 4.0 or higher
• Java 8
• Android 6.0 (23) SDK or higher
• Gradle 6.3
• Kotlin 1.3.72

SDK API docs

Ensure that you have mavenCentral listed in your project's buildscript repositories section:

buildscript {
    repositories {
        mavenCentral()
        ...                
    }
}

In the build.gradle file, add the library

implementation 'com.twilio:twilio-verify-android:(insert latest version)'

If you want to receive challenges as push notifications, you should add a firebase configuration to your project

• Add a project in Firebase to use cloud messaging for an application ID
• Add the google-services.json file to your project

More info here

See Verify Push Quickstart for a step-by-step guide to using this SDK in a basic Verify Push implementation.

• Clone the repo
• Follow the steps from Firebase configuration
• Get the Access Token generation URL from your backend (Running the Sample backend). You will use it for creating a factor
• Run the sample module using release as build variant

In order to run the sample app, you have to create a project and application in Firebase

• Add a project in Firebase to use cloud messaging for an application ID (you can use com.twilio.verify.sample)
• Move the google-services.json file you downloaded from Firebase console into the root of sample directory.

• Configure a Push Credential for the sample app, using the same Firebase project you configured
• Configure a Verify Service, using the Push Credential for the sample app
• Go to: https://www.twilio.com/code-exchange/verify-push-backend
• Use the Quick Deploy to Twilio option
  • You should log in to your Twilio account
  • Enter the Verify Service Sid you created above, you can find it here
  • Deploy the application
  • Press Go to live application
  • You will see the start page. Copy the url and replace index.html with access-token.(e.g. https://verify-push-backend-xxxxx.twil.io/access-token). This will be your Access Token generation URL

• Press Create factor in the factor list (main view)
• Enter the identity to use. This value should be an UUID that identifies the user to prevent PII information use
• Enter the Access token URL (Access token generation URL, including the path, e.g. https://verify-push-backend-xxxxx.twil.io/access-token)
• Decide if you want to enable push notifications for challenges associated to this factor. If you disable this option, push notifications will not be sent and you will get the factor's pending challenges only in the factor screen (pressing the factor)
• Press Create factor
• Copy the factor Sid

• Go to Create Push Challenge page (/challenge path in your sample backend)
• Enter the identity you used in factor creation
• Enter the Factor Sid you added
• Enter a message. You will see the message in the push notification and in the challenge view
• Enter details to the challenge. You will see them in the challenge view. You can add more details using the Add more Details button
• Press Create challenge button
• You will receive a push notification showing the challenge message in your device.
• The app will show the challenge info below the factor information, in a Challenge section
• Approve or deny the challenge
• After the challenge is updated, you will see the challenge status in the backend's Create Push Challenge view

You can silently approve challenges when your app already knows that the user is trying to complete an action (actively logging in, making a transaction, etc.) on the same device as the registered device that is being challenged.

You can enable the option "Silently approve challenges" for a factor. After enabling it, every challenge received as a push notification when the app is in foreground for that factor will be silently approved, so user interaction is not required. The option will be saved for the session, so the selection will not be persisted.

By default, logging is disabled. To enable it you can either set your own logging services by implementing LoggerService and calling addLoggingService (note that you can add as many logging services as you like) or enable the default logger service by calling enableDefaultLoggingService. Your multiple implementations and the default one can work at the same time, but you may just want to have it enabled during the development process, it's risky to have it turned on when releasing your app.

You may want to log only certain processes that are happening in the SDK, or you just want to log it all, for that the SDK allows you to set a log level.

• Error: reports behaviors that shouldn't be happening.
• Info: warns specific information of what is being done.
• Debug: detailed information.
• Networking: specific data for the networking work, such as request body, headers, response code, response body.
• All: Error, Info, Debug and Networking are enabled.

To start logging, enable the default logging service or/and pass your custom implementations

TwilioVerify.Builder(applicationContext).apply {
  if (BuildConfig.DEBUG) {
    enableDefaultLoggingService(LogLevel.Debug)
    addLoggingService(MyOwnLoggerService1())
    addLoggingService(MyOwnLoggerService2())
  }
}.build()

You can control Verify API error codes listed here by following the next example:

twilioVerify.createFactor(factorPayload, { factor ->
  // Success
}, { exception ->
  (exception.cause as? NetworkException)?.failureResponse?.apiError?.let {
    // Gets Verify API error response
    Log.d(TAG, "Code: ${it.code} - ${it.message}")
  }
})

Check an example here

You can get the cause for an error accesing the associated exception

twilioVerify.updateChallenge(updateChallengePayload, {
  // Success
}, { exception ->
  if (exception.cause is ExpiredChallengeException) {
    // Handle expired challenge case
  }
})

You can find the associated exceptions for validations here

You can update the factor's push token in case it changed, calling the TwilioVerify.updateFactor method:

val updateFactorPayload = UpdatePushFactorPayload(factorSid, newPushtoken)
twilioVerify.updateFactor(updateFactorPayload, { factor ->
  // Success
}, { exception ->
  // Error
})

Firebase provides a method to be notified when the push token is updated. See FirebasePushService in the sample app. You should update the push token for all factors.

You can delete a factor calling the TwilioVerify.deleteFactor method:

twilioVerify.deleteFactor(factorSid, {
  // Success
}, { exception ->
  // Error
})

You can clear local storage calling the TwilioVerify.clearLocalStorage method:

twilioVerify.clearLocalStorage {
  // Operation finished
}

Note: Calling this method will not delete factors in Verify Push API, so you need to delete them from your backend to prevent invalid/deleted factors when getting factors for an identity.

This project wolcomes contributions. Please check out our Contributing guide to learn more on how to get started.

Apache © Twilio Inc.