An access control server, also referred to as ACS, is built as part of the 3-D secure (3DS) protocol to prevent fraudulent online transactions. ACS provides the necessary high-level security needed to keep transactions safe and secure, and is normally deployed by card issuers. This allows said issuers to use different secure forms of authentication when it comes to authorising transactions based on what was initiated by the user.

An ACS is usually deployed as a remote backend application, which can run in a controlled and secure environment. As the ACS runs in a secure environment, it is almost completely possible to guarantee its security. The same is not true for client devices running vendor applications, such as banking apps, that initiate and process the transactions and authentications required by the ACS. This is because most vendors treat the client environment as hostile and unsafe.

It is incredibly important that the device which displays the transaction information is also protected. Why? Because most devices are vulnerable to a numerous array of attacks and malware infections. 

One of the easiest places to see these types of vulnerabilities play out is in the Android ecosystem, since most device vendors do not ship updates to devices that run operating system (OS) versions more than a couple years old (if at all). Yet sadly, as an online vendor, there is little you can do to ensure that your user’s device is running an up to date OS version. In most cases, users aren’t aware of the risk that is attached to using an outdated OS, or what happens once hackers get root privileges on their device. If you too are unsure, be sure to check out this brief overview on privilege escalation. 

Ultimately, the point to take away here is that regardless of the SCA method used in authorising a transaction or authenticating a user, if the transaction is not properly protected, there will be room for fraudulent interceptions or attacks.

When a transaction is initiated on a mobile application, such as a payment, the server responsible for processing that transaction delegates the authorisation process to the access control server. The ACS then reviews the details of the transaction, such as the amount to be deducted from the payer’s account. If the ACS is unsure about the accuracy of the initiator’s identity, the ACS challenges the transaction initiator to prove that they are in fact the legitimate owner of the transacting account. 

Before PSD2, the primary way to challenge the user’s identity was to send a one-time pin to the phone number associated with the payer’s account. Fortunately for today’s users, this method has proven to be grossly insecure and is no longer considered a secure form of SCA nor is it PSD2 compliant. Under the newest rules, users must use two of three factors to authenticate themselves when accessing data and giving payment instructions. The factors are something you know, something you have, or something you are. 

If the ACS challenges the transaction initiator, it will select one of these modes, such as a password, a one-time token, or the user’s fingerprint. The selection depends on the issuer's requirement and specific interpretation of the 3DS specification. After a decision is made about what mode of authorisation is required, the user is prompted to complete the transaction by completing any of the actions required by the ACS. 

For more information about PSD2 SCA, be sure to check out the article on Unlocking Strong Customer Authentication. For more info about SMS vulnerabilities, please look to our SMS for SCA and OTP via SMS blog posts.

The Okay solution protects user information and confidential transactions by preventing attacks. And this is Okay’s primary goal: to provide a high level of security to ensure that the integrity of the transaction is never compromised. To do this, the Okay solution is made up of two important components: the Okay SDK and the Okay secure server. 

The Okay SDK communicates directly with the Okay secure server through a unique secure communication channel that is established between the SDK and the secure server. Most users typically connect their servers directly to the Okay secure server when no ACS is available, but the approach is somewhat the same. 

When an ACS decides to challenge a user, and a decision is made on what mode of authorisation is needed for a particular transaction based on its internal rule engine, it sends a request to the Okay secure server using Okay APIs. Note that this communication happens using end-to-end encryption between the ACS and the Okay server.

The Okay secure server then wakes up the SDK and initiates a session between the SDK and the secure server through a secure communication channel. When the Okay SDK receives the transaction data from the secure server, it displays a secure screen to the user with the transaction data transferred from the Okay server to the SDK. The Okay SDK waits for the user’s response and then communicates the response back to the Okay secure server. 

During the transaction authorisation process, about six different security mechanisms are being triggered dynamically to ensure the integrity of the transaction. The Okay secure server then returns the user’s response to the ACS. The ACS will proceed to inform the server processing the transaction about the status of the transaction. The result is then displayed to the user on their account or the device used to initiate the transaction.

For more detailed and technical guidance on how to use our APIs in your ACS server, please check out the blog post on Setting up Two Factor Authentication, and our documentation page that helps you integrate the Okay app with your service.