Strong Customer Authentication

Introduction

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

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
note

For each use case that requires 2FA, your solution must use the correct type of key pair (restricted or unrestricted). See the following table for a full list of which type of key pair is required for each use case.

For detailed information on device binding and the types of key pairs, see the device binding guide.

Use cases that require 2FA

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):

Use case SCA via Device Signing? Minimum security key type required SCA via SMS OTP?
Authorized person (add, delete) Yes Restricted Yes
Business Data Change:
  • Update business details
  • Add/delete authorized persons
Yes Restricted Yes
Cards 3DS Yes Unrestricted Yes
Cards PIN Change Yes Restricted No
Cards Secure View Yes Restricted No
Cards Push Provisioning Yes Restricted Yes
Cash operations with Viacash Yes Restricted Yes
Credit/Debit Clearing Transactions (if the Clearing Profile has the value "customer_authentication": true) Yes Restricted Yes
Customer/Person Data Change: Add/change mobile number No N/A Yes
Customer/Person Data Change:
  • Personal details
  • Address
  • Delete mobile number
Yes Restricted Yes
Device Binding No N/A Yes
Login Yes Unrestricted Yes
Mobile Number Verification No N/A Yes
SEPA Credit Transactions Yes Restricted Yes
SEPA Credit Transactions Batch Order Yes Restricted Yes
Standing Order (create, update, cancel) Yes Restricted Yes
Timed Order (create, cancel) Yes Restricted Yes
Trusted IBAN (add, delete) Yes Restricted Yes

Implement SMS OTP

Prerequisites

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

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.

note

For businesses, you can use the ID of any person related to the legal entity.

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 below for more information.

Implement device signing

Login via device signing

note

Login via device signing must use the unrestricted key pair.

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:

Copy
Copied
POST :env/v1/mfa/challenges/devices

Example response:

Copy
Copied
{
  "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:

Copy
Copied
PUT /mfa/challenges/devices/{device_id}

Example response:

Copy
Copied
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.

note

When authorizing customer data changes via device signing, you must use the restricted key pair.

Customer Data Change Authorization via Device Signing

Transaction authorization via device signing

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

note

When authorizing transactions using device signing, you must use the restricted key pair.

Transaction Authorization via Device Signing

Change request process

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

DiBa: Authorization 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:

Copy
Copied
{
  "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:

Copy
Copied
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:

Copy
Copied
{
    "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:

Copy
Copied
{
    "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:

Copy
Copied
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.