As Telestax consolidates websites, on February 1, 2020, will be directed to

12 Apr Securing Your Transactions with Restcomm – Part 1

Nowadays most web-based services require you to authenticate or validate your intentions in some way. Whether it’s an online banking application securing or validating your transaction, or simply your favorite blog service authenticating your login attempt, a strong validation of your action will confirm your intentions and push the action liability to the user. The more individuals rely on web-based services for their work or daily life, the more pressure falls on service providers to strengthen their security and validation procedures. Even EU regulators are made to put an eye on it by enforcing Strong Authentication as part of the PSD2 package.

Now, what does this mean for communication service providers?There are many ways to secure or validate an online transaction, but as part of this, the web service should be using a different channel than the one delivering the service with a unique element that can identify the user like his personal MSISDN (phone number). How can you create an authentication or validation procedure on top of the phone number, voice and SMS? You got it, CPaaS comes to the rescue!

In this blog series I will explain how to leverage the Restcomm SMS and Voice capabilities to create a strong authentication system in order to enforce security and the liability of your users.

Using SMS Two-Factor-Authentication (2FA) or One-Time-Password (OTP)

The most widely implemented solution for strong authentication is undoubtedly Two-Factor-Authentication (2FA), also known as One-Time-Password (OTP). In this process, the user is prompted to insert his personal phone number. Then, a unique token is generated and sent on the backend, followed by the user receiving a prompt to insert the token received for validation. This is often the case for banking transactions or other online transactions that require retro-compatibility with various kinds of communication devices.

To exemplify how this process can be implemented I have divided the architecture into the following components:

  • Web Front-End: simple HTML front-end to manage input/output of number and token;
  • Backend Script: node.js and JSON based to serve as middleware between FE and RC;
  • Restcomm: Restcomm SMS API to send the token to a specific number.
All of these components can be found in my Github account with instructions on how to use them. Feel free to make comments or propose changes directly.

So what’s under the hood?

1. Collecting The Number

On the frontend, I’m presenting a very simple HTML page with a form that collects the phone number below.Collecting The Number

Behind this page, there is an HTTP Request to the node-js backend sending that number.

2. Generating The Token

The HTTP Request referred to in the last step is triggering a simple node.js script that generates a 6-digit token and temporarily stores it along with the phone number collected in a JSON file like the following:


3. Sending The Token

Continuing as part of the backend process, the token is sent over SMS to the number collected. The simplest way to do this is to send it over the network using the Restcomm SMS API:

var options = {
                url: 'https://' + rc_server + '/' + rc_path,
                auth: {
                    username: rc_accountSid,
                    password: rc_accountToken
                form: {
                    To: mobilenumber,
                    From: serviceName,    
                    Body: 'Your OTPApp token is: ' + token
    if (err) { return console.log(err); }
        // console.log("[%s] DEBUG - Message Sent - Report Received:",timestamp);
        // console.log(body);

You can grab the complete sample HERE.

If the SMS kick is successful, you should receive the following to your mobile:

4. Validating The Token

Naturally, the next step is naturally the token validation. You should have been redirected by now to that page as part of the flow. Simply use the form to insert the token received as pictured below.

Behind is another call to the node.js script to collect the token inserted and to look at the JSON structure. If successful, the script will simply delete the entry and return to the Token-OK page. Unsuccessful attempts will return the Token-NOK page:

Keep in mind that all components were structured with the sole purpose of showing how you can use Restcomm SMS API as part of the 2FA/OTP process and therefore are jumping over several security enforcement steps to simplify this example. One of the beauties of a full-stack CPaaS platform is that there are 1000 different ways to create the same service, some more efficient than others.

In this post, it is assumed that you have an SMS termination link associated with your Restcomm account. In Restcomm you can have different SMPP interconnection for each account or sub-account. This is called “Bring Your Own Carrier”.

You can learn how to do this HERE.

Stay tuned for “Securing Your Transactions with Restcomm – Part II” where I’ll be explaining how to use Restcomm Voice capabilities to enforce Strong Authentication.

No Comments

Sorry, the comment form is closed at this time.