Skip to contentSkip to navigationSkip to topbar
On this page

Verify Push Client Library Technical Overview



Data model

data-model page anchor

The data model does not require any PII (such as phone or email).

Verify Push Data Model.

  • Service: an organization or environment (e.g. stage, prod). Contains configurations for all verification methods available through the Verify platform (SMS OTP, Voice OTP, Email OTP, Push Verification, TOTP). A Twilio [sub]account can have multiple Services. Each Service contains multiple Entities that are not shared across Services.
  • Entity: a user or other identity that needs verification. An Entity can contain multiple Factors.
  • Factor: a verification method, which involves an exchange of secrets via a communication channel. For factor_type push, which is based on public-key cryptography, the Factor contains the public key of the private-public keypair generated by a registered device along with its metadata. A Factor contains multiple Challenges.
  • Challenge: a single verification attempt of an Entity using a Factor. A single Factor has multiple Challenges.
  • Access Token: an authentication token that a client app (e.g. Android app) uses to authenticate its request to the Verify Push API when creating (i.e., enrolling or registering) an Entity and/or Factor.
  • Webhook: a config that specifies that Verify Push notifies your app backend of an event.
Mobile Sample App Demo

Watch this demo to see how the data model is used to register a user/device and verify a user. The demo uses the Android Sample App(link takes you to an external page) and Sample Backend(link takes you to an external page). These samples are like transparent versions of a real mobile app and app backend integrated with Verify Push, but they expose the API calls that are being made and the data exchange behind the scenes.

Watch(link takes you to an external page)
Web Sample App Demo

Watch this demo to see how the data model is used to register a user/device and verify a user. The demo uses the Web Sample App(link takes you to an external page) (contact sales(link takes you to an external page) to request access) and Sample Backend(link takes you to an external page). These samples are like transparent versions of a real web app and app backend integrated with Verify Push, but they expose the API calls that are being made and the data exchange behind the scenes.


Verify Push Client Library (SDK) involves two main sequences:

  1. Register user and device
  2. Verify a user
VerifyPushSequenceDiagram.

How to Implement Silent Device Approval

how-to-implement-silent-device-approval page anchor

By optionally implementing Silent Device Approval within the Verify Push Client Library, you can silently approve challenges without push notifications 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. This results in an authentication that is completely invisible to the user. While implementation details will vary, here are some suggested steps:

  • In order to be confident about the user's intent, the challenge approval should be done when the app is in foreground during the flow of the action that is being approved (e.g. immediately after the user taps "login").

  • Identify the device starting the action and create a challenge for the factor linked to that device (a factor only represents one device).

  • If you want to send challenges for multiple devices (factors) or if you want to be sure that you're approving the correct challenge, there are two options:

    • Include the associated challenge sid for the action in the response to the device and validate that it's the expected challenge sid before approving it.
    • Assign a transaction id to the started action and include it in the response to the device, and add the transaction id to the challenge's hidden details, so before approving the challenge you can get the challenge's hidden details to validate it is the expected challenge
  • To receive the challenge on the client-side, you can:

    • Implement a strategy to listen for incoming push notifications when the app is in foreground and after some seconds, poll for pending challenges just in case the push notification did not arrive.
    • Poll for the latest pending challenge for an immediate approval, if your backend implementation can guarantee that the challenge was already created.

Ready to start building?

ready-to-start-building page anchor

Check out these quickstarts for step-by-step instructions:

Check out another demo of Verify Push being used for login authentication:

Check out this webinar for Getting Started with Verify Push(link takes you to an external page)

Need some help?

Terms of service

Copyright © 2024 Twilio Inc.