Contact us

FREE TRIAL

Out of Band Authentication: Practical use cases for online payments within 3DS2

NO NAME
Out of Band authentication is, by definition, an alternative authentication method that applies a communication path that is not in direct association with the path for the initial login to the merchant app/web browser. It relies on two completely separate communication channels instead of one. This makes for a sophisticated authentication solution proven to be successful in ensuring heightened security measures. Continue reading to get a detailed overview of OOB authentication flows and practical use cases.  

Out of Band authentication is, by definition, an alternative authentication method that applies a communication path that is not in direct association with the path for the initial login to the merchant app/web browser. It relies on two completely separate communication channels instead of one. This makes for a sophisticated authentication solution proven to be successful in ensuring heightened security measures. Continue reading to get a detailed overview of OOB authentication flows and practical use cases.  

What is OOB Authentication?

Out of band authentication (OOBA) is a type of two-factor authentication (2FA) that uses two different channels in order to deliver successful and secure authorization of online payments. The first channel is for making the transaction/purchase, and the second channel is the authentication channel, used for verifying the identity of the cardholder. By separating the process into two channels, using both the cardholder's internet and mobile wireless connection, the chances of compromising the transaction/account are greatly reduced. It is not likely that an attacker would be able to compromise both channels in the short timespan necessary for an online transaction to take place.

OOB authentication is widely used by financial institutions as well as organizations demanding sophisticated security requirements. It is an effective way for improving cybersecurity and known hacking methods such as ''man-in-the-middle'' attacks.

OOB Authentication General Workflow Overview

As mentioned, OOB authentication assumes two completely separate channels for conducting the successful processing of a transaction. Since it is a form of 2FA, necessary authentication components are something the user knows (password/PIN/OTP), something the user owns (smartphone/HW or SW token) or something the user is (biometry, fingerprint, face recognition).

A common example for implementing OOBA is for making an internet banking transaction. The cardholder logs in to their internet banking account on their laptop. Upon entering the transaction details, the cardholder is recevies an SMS OTP on their mobile phone to verify the transaction. And there it is - two completely separate channels, internet and wireless network, participating in achieving heightened online payment security.

OOB Authentication and Fraud Prevention

Typically, additional authentication is necessary when an Issuing bank's risk scoring engine detects a transaction that results in a score higher than the set threshold for frictionless transactions. Depending on the risk level, the cardholder needs to apply a more sophisticated means of authentication. This is when out of band authentication comes into play, assuming two different security elements obtained through different channels.

The possession element is the smartphone registered for receiving authentication request notifications. Following are the knowledge (OTP, PIN, etc.)  or inherence (biometry) security elements. Depending on the cardholder's selection, they are required to complete the chosen authentication challenge.

OOB authentication can be done using a single device (different apps running on the same device simultaneously), multiple devices (e.g., smartphone and a tablet), or in case of absence of authentication apps, by entering an SMS OTP into a designated field within the merchant's app.

OOB Authentication Flow within 3D Secure 2

Out of band authentication is apart of the EMVCo 3D Secure protocol and is proving to effectively combat malicious attacks directed towards online payments. What makes this approach successful is the combination of active components necessary for the functioning of 3D Secure environment. Those components are namely 3DS Requestor, 3DS Server, ACS (Access Control Server), and the Directory server.

To better understand the authentication flow, let's review three possible use case scenarios when it comes to OOBA.

     Out of Band authentication - Single Device Flow

OOBA enables authentication outside the merchant's shopping app, using an authentication application installed on the cardholder's device. Out of band checkout flow is triggered when an authentication app installed on the cardholder's device is identified as a second authentication channel. The mentioned application can be any of the following:

  • Issuer's mobile banking app
  • Issuer's app designed specifically for authentication purposes
  • Third-Party authentication app

Within this flow, the cardholder is switching between the 3DS merchant app to the authentication app and finally back to the 3DS merchant app displaying the transaction/payment confirmation screen.

Let's review the entire checkout flow for a single device out of band authentication. This example includes push notification and fingerprint recognition as a means of authenticating the cardholder.

  1. This can be due to merchant whitelisting or card-on-file transactions.
  2. By selecting the ''Confirm order'' option, the 3DS2 flow is triggered.
  3. The 3DS Requestor communicates with the 3DS Server in order to initiate the authentication process. The sent message is received by the ACS which determines the risk of the transaction based on received data.
  4. ACS evaluates the transaction as a non low-risk transaction and challenges the cardholder. The 3DS requestor communicates with SDK in order to trigger the authentication flow.
  5. The cardholder receives a push notification on the registered device. Push notification is considered a first authentication factor; i.e. possession of a device.
  6. By taping on the push notification, the cardholder is redirected to the Issuer app presenting the authentication screen.
  7. Upon checking the transaction details, the cardholder either declines or confirms the authentication request.
  8. By selecting confirm, the Issuer app will trigger the fingerprint recognition process. In case that the fingerprint is not recognized, a fallback method must be included.
  9. If the second security element (fingerprint) is confirmed, the cardholder is automatically redirected back to the merchant's app to complete the checkout process. By selecting ''Continue'', the cardholder is displayed a checkout confirmation screen indicating a successful transaction.

    Out of Band authentication – Multiple device flow

Numerous studies state that the vast majority of online transactions within Europe are initiated from a laptop, PC, or tablet. Research also suggests that this pattern is going to be relevant for the next two to three years. OOB authentication enables cardholders to conduct their online shopping using a laptop, while authentication can be controlled by using their mobile device.

The following flow covers an example of a cardholder purchasing items online on a merchant website (HTML flow). We will review the cardholder activity both on the laptop and on the registered user device.

  1. The cardholder is shopping from within a browser using their laptop. As in the previous example, we will assume that the cardholder is familiar with the merchant and necessary credentials are automatically filled out.
  2. Upon adding the items to the shopping cart and selecting the ''Confirm order'' option, the 3DS checkout flow is initiated.
  3. The 3DS Server communicates with the 3DS Server in order to initiate the authentication flow. The cardholder is presented with a loading screen indicating backend activity on their desktop browser.
  4. The ACS challenges the cardholder and pushes the 3DS challenge screen for multiple device OOB flow.
  5. The 3DS Requestor initiates the challenge flow as the ACS contacts the OOB backend to initiate authentication flow.
  6. ACS sends a push notification to the cardholder's registered device. This is considered the first factor of authentication.
  7. By selecting the push notification on the device, the cardholder is presented with the app's authentication screen. Upon transaction review, the cardholder selects either decline or confirm option presented on the screen.
  8. By confirming the transaction on the registered device, a second authentication factor needs to apply. In this case, we will again use fingerprint recognition. In case that the fingerprint is not recognized, a fallback method must be included.
  9. If the fingerprint is recognized, a confirmation screen will be displayed within the authentication app.
  10. After completing authentication using the registered device, transaction confirmation within the browser displays.

     One Time Passcode via SMS

In the case where the cardholder does not have access to an authentication app, the alternative authentication method is OTP via SMS. We consider OTP (One Time Passcode) as a possession element indicating ownership of a registered device.

The following flow assumes a single device OOB authentication, including a merchant app and an OTP sent via SMS to the cardholder's registered device.

  1. The cardholder adds wanted items to the online shopping cart and proceeds to the checkout page. We will assume that the merchant is familiar to the cardholder from previous purchases. Necessary credentials such as payment card, billing address, and shipping address are already filled out.
  2. Cardholder selects the ''Confirm order'' option.
  3. The 3DS Requestor communicates with the 3DS Server and triggers the authentication flow.
  4. ACS challenges the cardholder with an additional authentication step and pushes the 3DS challenge screen. The screen is specific for OTP via SMS flow, including a field for OTP entry.
  5. The 3DS Requestor communicates with the SDK to initiate the challenge flow.
  6. ACS sends an SMS to the cardholder's registered device containing an OTP.
  7. The cardholder enters the delivered OTP in the designated OTP field.
  8. By selecting the ''Submit'' option, OTP goes to ACS for validation.
  9. SDK validates the entry with ACS, and ACS communicates the authentication result to the 3DS Requestor.
  10. A confirmation page indicating a successful transaction displays to the cardholder.

If you want to find out more, contact our ASEE 3D Secure Team or download the datasheet.

Want to learn more about cybersecurity trends and industry news?

SUBSCRIBE TO OUR NEWSLETTER

CyberSecurityhub

chevron-down linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram