The data model does not require any PII (such as phone or email).
Resource definitions
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 and Sample Backend. 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 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 (contact sales to request access) and Sample Backend. 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:
Register user and device
Verify a user
How to Implement Silent Device Approval
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?
Check out these quickstarts for step-by-step instructions: