Strong Customer Authentication

Introduction

What is Strong Customer Authentication?

Strong Customer Authentication (SCA) is a regulatory requirement imposed by the European Payments Services Directive (PSD2) guidelines on all banks and payment service providers in the European Economic Area (EEA).

PSD2 enforces Strong Customer Authentication (SCA) that requires multi-factor authentication on all online payments in the EEA to reduce fraud and make online payments more secure.

To meet SCA requirements, you have to implement additional authentication methods in your solution. SCA requires at least two-factor (2FA) authentication, including at least two of the following categories:

• Knowledge—something you know: This could be a personal identification number (PIN), a password, answers to "secret questions," or a specific keystroke pattern.
• Possession—something you have: This could be something in the user's possession, like a credit card, a smartphone, or a small hardware token.
• Inherence—something you are: This includes a biometric fingerprint pattern, an iris scan, or a voiceprint.

When is Strong Customer Authentication required?

Strong Customer Authentication is required in the following use cases:

Login

According to the revised European Payments Services Directive (PSD2) SCA requirements, you need to implement two SCA methods, one as primary and the other to be used as a fallback to enable your customers to log into their accounts using 2FA in the following cases:

• Accessing their account online for the first time, including accessing the following information:

  • Their account balance without disclosing any sensitive payment data.
  • Transactions executed in the last 90 days.
• Accessing transaction records that are older than 90 days.
• More than 180 days have elapsed since the last time the customer had been authenticated using SCA.

Customer data changes

For data changes, customers are also required to use 2FA to ensure the security of customers data and prevent fraud.

Transaction authorization

Transaction authorization also requires 2FA to ensure the security of the customer's balance.

For more information about all the use cases that require 2FA, check the dedicated section.

This guide explains how to implement two-factor authentication (2FA) for SCA in your solution using Solaris' APIs.

2FA methods

Solaris offers two methods for 2FA:

SMS OTP

In this method, Solaris sends a 6-digit OTP challenge via text message to the verified mobile number of the customer initiating the action.

Pros:

• Best solution for web apps
• Security

Cons:

• Higher cost
• Dependency on mobile operators

Device signing

In this method of 2FA, Solaris creates a device signature challenge to verify the device of the customer initiating the action. The customer must have already registered their device using device binding.

Pros:

• More secure than SMS
• Cost-effective
• Eliminates dependency on mobile operators

Cons:

• Can only be used on mobile apps

Use cases that require 2FA

Restricted and unrestricted key pairs

Your customers can authorize actions using either a restricted or an unrestricted key pair depending on the type of action:

• Unrestricted key pair does not require user authentication.
• Restricted key pair requires user authentication via biometrics (e.g., Touch ID or Face ID). For example, you need to combine the privateKeyUsageflag with the userPresence or touchIDAny in iOS or setUserAuthenticationParameters() in Android.

The table below lists all of the use cases that require SCA, and which method is supported for each one (either device signing, SMS OTP, or both):

Implement SMS OTP

Prerequisites

You must implement the following processes in your solution in order to use SMS OTP for 2FA:

• Customer mobile number verification
• Change request process

Login via SMS OTP

For each login attempt, your solution must trigger the following two-step process:

Step 1: Create SMS challenge

First, your solution must call the POST /mfa/challenges/sms method to initiate the 2FA process. In the request body, provide the person_id of the customer initiating the request. This will send an SMS to the person's verified mobile number.

Click here to go to the API reference.

Step 2: Verify OTP

Next, your customer must input the OTP from the SMS into your solution, and you must pass this to Solaris using the PUT /mfa/challenges/sms/{sms_id} method.

Click here to go to the API reference.

Customer data change via SMS OTP

Solaris handles customer data changes using the change request process. See the change request section below for more information.

Transaction authorization via SMS OTP

Solaris handles transaction authorizations using the change request process. See the change request section for more information.

Implement device signing

Login via device signing

The process of logging in via device signing works as follows:

1. Your solution initiates a device signing challenge.
2. Solaris creates an authentication code and sends it to the customer's device over your solution (i.e., over the API).
3. The customer's device signs the authentication code and provides it to your solution, which then sends it to Solaris for verification via the API.
4. Based on the cryptographics, Solaris checks to see if the code was signed by a known device that is under the customer's control. If this is the case, then the challenge succeeds.

Step 1: Create device signing challenge

Call the following POST endpoint to initiate the device signing challenge. In the request body, submit the device_id of the customer's bound device that should be used for confirming the challenge.

Request URL:

POST :env/v1/mfa/challenges/devices

Example response:

The API response returns an id, which is the challenge ID required for the next step.

{
  "id": "6642d15e-8f6b-4d28-9186-cdd61d80032a",
  "type": "signature",
  "created_at": "2022-03-18T14:50:04Z",
  "expires_at": "2022-03-18T14:55:04Z",
  "string_to_sign": "string"
}

Click here to view the full API reference.

Step 2: Verify device signing challenge

Next, the customer's device must sign the string contained in the string_to_sign attribute of the response using its private key. The signed string must be provided in the next API call.

How to sign:

• Create a hash(SHA256) with the string_to_sign.
• Sign the hash with the device's private key.
• Encode the signature in ASN.1 format.
• Hex encode the ASN.1 format signature.

Submit the hex-encoded signature as the value of the signature attribute in the body of the following request:

Request URL:

PUT /mfa/challenges/devices/{id}

Example response:

HTTP/1.1 204 Challenge successful

Click here to view the full API reference.

Customer data change via device signing

Solaris handles customer data changes using the change request process. See the change request section below for more information.

Transaction authorization via device signing

Solaris handles transaction authorizations using the change request process. See the change request section below for more information.

Change request

Solaris has introduced the change request process in order to ensure the security of customers' data and accounts according to compliance and regulatory guidelines.

All customer data changes and transactions must be authorized using the change request process.

Diagram: Change request flow

Step 1: Initial API request

All Solaris API endpoints related to customer data changes and transactions require you to complete the change request process before they can be executed. When you create or update a resource via POST/PATCH, you will receive a 202 response with the status AUTHORIZATION_REQUIRED that looks like the following:

{
  "id": "d6c778822b2d7bd3b778935bcfd0d1d3csc",
  "status": "AUTHORIZATION_REQUIRED",
  "updated_at": "2017-10-20T22:27:35.000Z",
  "url": ":env/v1/change_requests/:id/authorize"
}

The response contains the id of the change request, which you must use in the next API call.

Step 2: Submit change request authorization

Next, you must create an authorization challenge for the customer—either using SMS OTP or device signing. Use the id returned in the previous API call in the request URL.

Click here to view the full API reference.

Request URL:

POST /change_requests/{change_request_id}/authorize

SMS OTP

In the body of the request, submit the following:

• person_id: The ID of the person who initiated the change request.
• delivery_method: Use mobile_number.

The customer will then receive an SMS OTP at their verified mobile number.

Example response:

{
    "id": "d6c778822b2d7bd3b778935bcfd0d1d3csc",
    "status": "CONFIRMATION_REQUIRED",
    "updated_at": "2017-10-20T22:28:35.000Z",
    "url": ":env/v1/change_requests/:id/authorize"
}

Device signing

In the body of the request, submit the following:

• person_id: The ID of the person who initiated the change request.
• delivery_method: Use device_signing.
• device_id: ID of the bound device that the customer must use to verify the change request.

The customer will then receive a device challenge on their bound device.

Example response:

{
    "id": "d6c778822b2d7bd3b778935bcfd0d1d3csc",
    "status": "CONFIRMATION_REQUIRED",
    "string_to_sign": "CHALLENGE_TO_SIGN", // only for device signing
    "updated_at": "2017-10-20T22:28:35.000Z"
}

The status of the change request will be set to CONFIRMATION_REQUIRED.

Step 3: Confirm authorization

Finally, you must collect the required input from the customer (depending on the delivery method) and submit it to the confirmation endpoint.

Click here to view the full API reference.

Request URL:

POST /change_requests/{change_request_id}/confirm

SMS OTP

Submit the following in the request body:

• person_id: ID of the person who initiated the change request.
• tan: 6-digit OTP provided in the SMS to the customer.

Device signing

Submit the following in the request body:

• device_id: ID of the bound device used to confirm the change request.
• signature: The signature provided by the bound device. See the device binding guide for more information.

Finally, the request status will be set to COMPLETED.