Vonage is excited to bring Silent Authentication into our Verify API! The Silent Authentication channel has been added as part of Verify V2 and is currently in the Alpha product phase. In this article, we'll walk through what it is, what it does, and how to use it. So, to get started, we'll answer the following:

What is Silent Authentication?

Silent Authentication is a recent development in personal authentication workflows that uses your mobile phone's Subscriber Identity Module (SIM) as your identity, checked against the carrier's records to make sure your number is active and genuine. Once a request has been verified, a consumer vendor/client can then hit the same endpoint each time a user wants to authenticate, which will be valid until the request expires, or is canceled by the client. What this effectively translates to is: using your mobile phone as your password.

What are the advantages of using Silent Authentication?

One-Time Passwords (OTP) are used extensively for two-factor authentication across the world. The de-facto main use of our Verify API is to use an OTP sent to a customer's SMS. Let's be honest here, though: as a customer, OTPs are annoying. Sure, it's an added layer of security (we'll get to why this is not necessarily true shortly). Still, for a vendor that relies on as few clicks or navigation points in a workflow (such as e-commerce), you're increasing the resistance to completing a flow (i.e. purchasing an item). E-commerce usually requires the path to least resistance, so from that perspective, Silent Authentication completely removes that extra step to logging in or checking out your cart.

Security is also a concern - it's a common misconception that 2FA makes user flow extremely hard to crack, but this does not take into consideration that SMS phishing is a highly prevalent attack vector used by scammers. By moving authentication directly between the carrier and the mobile device, the threat of phishing is removed.

Any disadvantages?

In true developer style, we wouldn't be doing our jobs right if we didn't point out that nothing is a "fix-all" when it comes to user verification - just like in engineering, there are tradeoffs. There are two main disadvantages to using it:

• Silent Authentication shares a common blocker with SMS verification in that the user requires a mobile device - there's no getting around this. While statistics show that smartphone ownership across Western nations is on a trajectory to hit above 90% soon (88% of the UK population owns a smartphone, for instance), it does not take into account a global audience where service quality or economics might be active blockers.

• The users' mobile must have cellular data enabled. It's a small step, but nevertheless an extra complication in a process you want to be as simple as possible.

How to make a Silent Authentication Verify Request

Synchronous vs. Asynchronous Integrations

I'm going to show you the synchronous method of implementing Silent Authentication, but it's worth nothing that can do either: this synchronous method relies on the device client to make a series of calls to complete, but you can use an asynchronous workflow without having to change anything. Every part of the workflow is also included in webhook callbacks to the URL of choice in the application setup.

So let's get started with the synchronous implementation. First off, we'll want to make a call to start the process:

Providing you have not hit throttle limits and the authorisation token is correct, you should get an HTTP 202 response with your request_id for reference and a check_url:

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

The check_url is a link to follow in order to continue the process, so you'll want your client-side code to do just that. When you follow it, you'll receive a variable number of 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 depending on whether the request is valid. If there is a problem with using the network, you'll get the following response:

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."
}

But, all being well, you'll get an HTTP 200 with the following example payload:

{
  "request_id": "31eaf23d-b2db-4c42-9d1d-e847e75ab330",
  "code": "si9sfG"
}

The last part of the workflow is to send the code to be checked, in the same way you would with the other verify channels.

POST https://api.nexmo.com/v2/verify/31eaf23d-b2db-4c42-9d1d-e847e75ab330 HTTP/1.1

Content-Type: application/json
{
  "code": "si9sfG"
}

The responses are the same as if you were checking a code delivered by the other workflows such as SMS, so if the code is valid:

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

Or, if there is an error:

{
   "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"
}

Yes, there are quite a few steps for the developer to implement in this solution, but the beauty is in the end user seeing a seamless experience. Correct phone, valid carrier? Done, you're logged in!

Stay Tuned

Silent Authentication marks the start of a series of products we're working on this year. You can register with us if you want to start using Silent Authentication to activate developer preview, and in the meantime - we've got some nifty products we're excited about in 2023. Want to keep up to date? Follow our Twitter Developer Account or check out our developer docs.