Silent Authentication Advanced - Asynchronous Implementation [Alpha]
Note: Silent Authentication Advanced is currently in alpha stage. Live supply onboarding is ongoing, which means end-to-end testing is not yet possible. Token retrieval from the device will not work until your carrier is supported. At this stage, all Silent Authentication Advanced documentation serves primarily as informational resources. You can use the Virtual Operator for development and testing purposes.
This guide explains how to implement Silent Authentication Advanced on Android using the Vonage Verify API. For more information about Silent Authentication Advanced, refer to the conceptual guide on Silent Authentication Advanced.
Silent Authentication Advanced is currently supported only on Android, with iOS support planned for a future release. For web browser implementation, refer to the guide on Silent Authentication Advanced for Web Browsers, which covers the desktop/laptop flow (QR code + Bluetooth proximity) and notes the mobile browser variant.
Silent Authentication Advanced currently only supports an asynchronous implementation. You must configure webhook endpoints to receive authentication results. Support for synchronous implementation is planned for a future release.
Prerequisites
- Vonage API account
- Application registered in the Network Registry. It's required for production use only. For non-production testing, use the Virtual Operator instead.
- Android device with a TS.43-enabled SIM card
- Webhook endpoints configured to receive asynchronous authentication results
Create an Application
To begin, go to the developer dashboard to create your application:
- Ensure that Verify is enabled under 'Capabilities'.
- Configure the Status URL to receive callback events.
- Generate a JWT using the Application ID and private key of the application.
Start a Verification Request
To start the Silent Authentication Advanced verification process, add the mode parameter to the workflow in your Verify request.
The following example illustrates the request structure. For a full runnable implementation, refer to the Verify API Specs.
{
"client_ref": "myPersonalRef",
"brand": "ACME",
"workflow": [
{
"channel": "silent_auth",
"to": "'$VERIFY_NUMBER'",
"mode": "advanced"
},
{
"channel": "sms",
"to": "'$VERIFY_NUMBER'"
}
]
}
Note: If you are using multiple channels, Silent Authentication Advanced must be the first channel listed in the workflow. Currently, only a single Silent Authentication channel can exist within a workflow.
If the Silent Authentication Advanced check fails, such as in cases of lack of network coverage, Vonage Verify will automatically switch to backup channels if defined in the workflow, including SMS or voice call.
Fetch the TS.43 Token
You can fetch the TS.43 authentication token from the SIM in two ways:
Using the Vonage Android Client SDK
You can use our Client Android SDK to fetch the TS.43 authentication token from the SIM, or directly implement the challenge-response flow using the Telephony API.
Using the Android Credential Manager API Directly
- Your application backend creates an OpenID4VP request with DCQL for TS.43 (nonce, aggregator JWT, hints).
- Next, the application sends a request to the Android Credential Manager API. At this stage, the user consents via the system UI.
- Android Telephony generates an encrypted TS.43 SD-JWT credential from the carrier entitlement server using the SIM.
Check the Token
The following example illustrates the request structure:
{
"token": "$TOKEN"
}
Note: The token parameter is mutually exclusive with the code parameter and applies only to Silent Authentication Advanced.
To complete the verification process, submit the token to the /v2/verify/:request_id endpoint. See the Verify API Specs for details on requests and responses.
Testing with the Virtual Operator
Note: The Virtual Operator supports backend API calls only. It does not simulate the full end-to-end token exchange flow with the device.
During integration, use +990 numbers to ensure deterministic Virtual Operator responses: even numbers indicate success, while odd numbers indicate failure. This will safely test callback and error handling. For more details refer to the Virtual Operator guide.