Synchronous Implementation

This guide explains how to implement silent authentication using the synchronous approach, where your backend waits for a direct response after redirecting the user.

Note: if using a Synchronous implementation, switching on Verify capabilities on the application dashboard is optional, as this only switches the ability to receive status webhooks (that are not required for a Synchronous implementation).

The following diagram shows the necessary steps to implement the synchronous version of Silent Authentication:

VonageApp BackendMobile AppVonageApp BackendMobile AppRequest Verification CodeCheck Verification CodeVerify phone numberPOST v2/verify202 OK (check_url, request_id)Response (check_url)GET check_urlSeveral 302 RedirectsHTTP 200 (request_id, code)Request (request_id, code)POST v2/verify/:request_id (code)HTTP 200 (status: completed)Response (Completed)

Request Verification Code

To start the silent authentication process, make a request to /verify endpoint. In the following example, the workflow specifies that Verify will first attempt to use Silent Authentication. If for any reason the request fails, it will then fallback to email OTP.

Note: if using multiple channels, silent authentication must be the first channel in the workflow.

To run the example, replace the following variables in the sample code with your own values:

Variable Description
JWT Authenticates the API request using JWT.
VERIFY_BRAND_NAME The name of your company or service, shown to the user in the verification message.
VONAGE_APPLICATION_PRIVATE_KEY_PATH Private key of your application.
VONAGE_APPLICATION_ID Application ID of your application.
VERIFY_NUMBER The phone number to send the OTP to, in E.164 format (e.g., +44111223344).
VERIFY_TO_EMAIL The email to send the OTP to.

Write the code

Add the following to request.sh:

curl -X POST "https://api.nexmo.com/v2/verify" \
  -H "Authorization: Bearer $JWT"\
  -H 'Content-Type: application/json' \
  -d $'{
	 "brand": "'$VERIFY_BRAND_NAME'",
   "workflow": [
      {
         "channel": "silent_auth",
         "to": "'$VERIFY_NUMBER'"
      },
			{
         "channel": "email",
         "to": "'$VERIFY_EMAIL_TO'"
      }
   ]
}'

View full source

Run your code

Save this file to your machine and run it:

sh request.sh

If the request is successful and the number is supported, you will receive a 200 Ok response containing a request_id and a check_url in the body:

{
  "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",
  "check_url": "https://api.nexmo.com/v2/verify/31eaf23d-b2db-4c42-9d1d-e847e75ab330/silent-auth/redirect"
}

Until the request expires or is cancelled, check_url can be used to perform a Silent Authentication check. Upon receiving this response, you need to make a

GET
request to the check_url from the mobile device you are trying to authenticate.

In order for the Mobile Network Operator to properly verify the user, the GET request must be made over a mobile data connection. See Android and iOS Libraries for information on how to force a mobile connection.

Once you've made the

GET
request, you'll receive a number of HTTP 302 redirects depending on the territory and carrier the target device is using:

HTTP/1.1 302 Found
Location: https://eu.api.silentauth.com/phone_check/v0.2/checks/31eaf23d-b2db-4c42-9d1d-e847e75ab330/redirect

Following the redirects will result in either a HTTP 200 or HTTP 409 response depending on whether the request is valid. If there is a problem with the network, you'll see a response like this:

HTTP/1.1 409 CONFLICT
Content-Type: application/json

{
  "title": "Network error",
  "detail": "The Silent Auth request could not be completed due to formatting or the carrier is not supported."
}

A full list of potential error codes can be found in the API Specification.

If the request is valid, you will receive an HTTP 200 response containing your request_id and a code:

{
  "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",
  "code": "si9sfG"
}

Note: To ensure a secure authentication check and mitigate against a potential man in the middle attack, store the original request_id and compare it with the request_id returned in the response. If the IDs don't match, the silent authentication check should be aborted. See our sample application for an example implementation of how to mitigate against the attack.

Check the Supplied Verification Code

Once the end-user receives the code, you must send a

POST
request to the /v2/verify/{request_id} endpoint, replacing {request_id} with the ID you received in the previous call.

To run the example, replace the following variables in the sample code with your own values:

Variable Description
JWT Authenticates the API request using JWT.
VERIFY_REQUEST_ID The request_id received in the previous step.
VONAGE_APPLICATION_PRIVATE_KEY_PATH Private key of your application.
VONAGE_APPLICATION_ID Application ID of your application.
VERIFY_CODE The verification code received by the end-user

Write the code

Add the following to check-verification-code.sh:

curl -X POST "https://api.nexmo.com/v2/verify/$VERIFY_REQUEST_ID" \
  -H "Authorization: Bearer $JWT"\
  -H 'Content-Type: application/json' \
  -d $'{
    "code": "'$VERIFY_CODE'"
  }'

View full source

Run your code

Save this file to your machine and run it:

sh check-verification-code.sh

Note: a code for a silent authentication workflow can only be checked once.

If the code is valid, you will receive a final response with the status completed:

{
   "request_id": "31eaf23d-b2db-4c42-9d1d-e847e75ab330",
   "status": "completed"
}

Or, if there is an error, you will see 'Invalid Code':

{
   "title": "Invalid Code",
   "type": "https://www.developer.vonage.com/api-errors/verify#invalid-code",
   "detail": "The code you provided does not match the expected value.",
   "instance": "bf0ca0bf927b3b52e3cb03217e1a1ddf"
}

At this point, your silent authentication verification is complete.