Main Components
Below is explained each component that participates in process of Strong Customer Authentication.
Authenticator app communicates with Authentication Service and receives push notifications from Push Service
The purpose of Authenticator app is to provide a user-friendly interface, where customer identifies himself via PIN and/or Biometric, as required by strong authentication, and authorizes any initiated by him action with convenient and transparent information in regard to initiated action. Salt Edge Authenticator app is a decoupled implementation of PSD2 Strong Customer Authentication (SCA) requirements.
What does “Decoupled” mean?
Decoupled implementation implies that Service Provider is directly asking customer to pass strong authentication. Salt Edge Authenticator app is independent from the online interface where action is initiated by customer. This SCA method allows the TPP to skip implementing anything regarding SCA at their customer to TPP interface, since everything is done between the Customer and the Service Provider.
Create and enrich ‘connection’ (enrollment flow)
- Scan and read QR code, or open from Deep Link. Start enrollment process (on backend side) after QR code is scanned or Deep Link is accessed.
- Get Service Provider configuration.
- Create and store a pair of RSA keys (‘private_key’ and ‘public_key’) in trusted storage.
- Create and store ‘connection’ model with reference to RSA keys.
- Send request to create ‘connection’ to Identity Service, providing ‘push_token’, ‘public_key’ and ‘return_url’.
- Get in response from Authentication Service the Sign in URL (’connect_url’ (2)).
- Open the Sign in URL (’connect_url’ (2)) in WebView, appealing to the Authentication Service.
-
Catch web redirect to
return_urland extract the ‘access_token’. - Add ‘access_token’ to the ‘connection’ model and save it persistent storage.
Process ‘authorization’ (strong authentication flow)
- Receive push notification via FCM/APNS, which contains ‘authorization_id’, ‘connection_id’.
- Display push notification to customer.
- Send request to Authentication Service to get ‘authorization’ by means of ‘authorization_id’ received from push notification.
- Get in the response from Authentication Service the encrypted ‘authorization’.
- Decrypt ‘authorization’ with connection ‘private_key’. ‘Authorization’ contains ‘authorization_code’, ‘title’ and ‘description’.
- Create ‘confirmation_request’, which contains ‘authorization_code’ and ‘confirm:true’ parameter. Sign the ‘confirmation_request’ with connection ‘private_key’.
- Send ‘confirmation_request’ to Authentication Service to confirm ‘authorization’.
Catch ConnectionNotFound error and invalidate related stored connection model
Push Service communicates with Authentication Service and Authenticator app.
The purpose of Push Service is to inform customers about the necessity to authorize any initiated via remote channel action in the Authenticator app.
Push Service does not participate in enrollment flow.
Notify customer about pending authorization (strong authentication flow)
- Push Service receives request from Authentication Service to send push notification to specific Authenticator app. In request are provided ‘push_token’, ‘authorization_id’ and ‘connection_id’.
- Push Service sends push notification via FCM/APNS at particular ‘push_token’, providing ‘authorization_id’ and ‘connection_id’.
Authentication Service communicates with any Web or Mobile app (e.g. merchant app, Web/Mobile Banking, TPP app, etc.), Identity Service and Core banking.
Authentication Service is the first point of contact when accessing Service Provider system, as any initiated by the customer action at first gets to Authentication Service, before it is processed further.
The purpose of Authentication Service is to accept and redirect incoming requests, as well as send outgoing requests. More specifically, Authentication Service is required to get credentials and to permit customers to access the specific functionalities, if customer’s credentials are successfully verified by Identity Service. Also, Authentication Service is getting payment orders, which are redirected to the Core banking. All the outgoing requests or responses are also being redirected to the correct destination.
Authenticate customer and redirect enrollment data (enrollment flow)
- Show QR code and Deep Link which contain ‘configuration_url’ (optionally, also the
connect_query) for Customer to get configurations and start enrollment process. - Receive requests from Authenticator app to get configurations via ‘configuration_url’ and respond with ‘connect_url’ and configurations.
- Redirect request to create new ‘connection’ to Identity Service, providing 'push_token', 'public_key' and 'return_url' .
- Redirect response from Identity Service to Authenticator app, providing Sign in URL (’connect_url’ (2)) and ‘session_token’ for Authenticator app to access specific “Sign in” page.
- Display “Sign in” web page of the Service Provider, assuming it’s located on Authentication Service.
- Get the customer's credentials or process any alternative method for authentication (depends on the methods used by Service Provider), as well as Second Factor Authentication (2FA), in case it is applicable.
- Redirect credentials to Identity Service for verification, providing also ‘session_token’.
- Redirect request from Identity Service to provide ‘access_token’ to the Authenticator app, by means of received from Identity Service ‘return_url’.
Redirect action initiation requests and data (strong authentication flow)
- Redirect incoming action initiation request from Web or Mobile app to Core banking for analysis. Most common action is payment order, where it is necessary to send in payment initiation request the payment order data (‘payee’ details and ‘amount’) to the Core banking.
- Receive from Identity Service the request to send notification to Push Service, with provided 'authorization_id', 'connection_id' and 'push_token'.
- Redirect incoming push notification request to Push Service.
- Receive from Authenticator app request to provide ‘authorization’ from Identity Service, with provided ‘authorization_id’.
- Redirect incoming request from Authenticator app to get ‘authorization’ to the Identity Service.
- Receive from Identity Service response with encrypted ‘authorization’.
- Redirect incoming response from Identity Service to the Authenticator app.
- Receive from Authenticator app the ‘confirmation_request’.
- Redirect the ‘confirmation_request’ to the Identity Service.
- Receive result of ‘authorization’ confirmation from Identity Service.
- Redirect the result of ‘authorization’ confirmation to the Authenticator app.
- Receive result of payment execution confirmation from Core banking.
- Redirect the result of successful payment execution to the Web or Mobile app.
Identity Service communicates with Authentication Service and Core banking.
The purpose of Identity Service is to process and store customer identities, roles, credentials, and add the necessary functionality in order to implement SCA. Hence, besides standard functionality, in Identity Service should be implemented additional functionalities and an API, as an extension to the existing Identity Service. The extension (additional functionality and API) processes received from Core banking information and appeals to the Authenticator app via Authentication Service in order to get either action confirmation or denial from the customer.
There is a little effort from Service Provider in order to implement and extension Identity Service with 6 API end-points: Connect to Service Provider; Get Access Token; Revoke Access Token; Show Authorizations List; Show Authorization; Confirm or Deny Authorization. Salt Edge has developed the SCA solution with such an architecture, having Identity Service in infrastructure of Service Provider, in order not to have any access to the personal information/credentials of the customer. All related to the customer private data is isolated from any third party or application and is controlled exclusively by the Service Provider. Example of the Identity Service is provided by Salt Edge for architecture understanding and to easen implementation.
Create and enrich ‘connection’ (enrollment)
- Receive incoming request from Authenticator app to create new ’connection’, which contains ‘push_token’, ‘public_key’ and ‘return_url’.
- Create and store ‘connection’, which contains ‘public_key’, ‘return_url’ and ‘push_token’.
- Return successful result of ‘connection’ creation to Authentication Service.
- Receive customer credentials from Authentication Service.
- Verify credentials, create 'access_token' for 'connection' for customer.
- Return 'return_url' and 'access_token' to Authentication Service.
Process Strong Customer Authentication (strong authentication flow)
- Receive request to initiate strong authentication from Core banking, with provided 'authorization_code', 'title' and 'description'.
- Create ‘authorization’ for particular ‘user’ and add to it 'authorization_code', 'title' and 'description'.
- Find ‘connection’ related to the particular ‘user’ and request Authentication Service to send push notification, provide ‘authorization_id’, ‘connection_id’ and ‘push_token’, which is stored in ‘connection’.
- Receive incoming request to provide ‘authorization’ by ‘authorization_id’ from Authentication Service.
- Verify the signature of the received request by means of ‘public_key’.
- Encrypt ‘authorization’ by means of ‘public_key’.
- Return encrypted ‘authorization’ to Authentication Service.
- Receive incoming request to confirm ‘authorization’ from Authentication Service.
- Verify the signature of the received request by means of ‘public_key’.
- Compare received 'authorization_code' from Authentication Service with original 'authorization_code' from 'authorization'.
- Return successful results to Authentication Service to send result of verified ‘authorization’, and to Core banking to send result of SCA.
Core banking communicates with Authentication Service and Identity Service.
The purpose of Core banking is support a bank's most common transactions, to process and store them. Core banking system defines the incoming request for any action initiation and decides what exact process has to be initiated. In terms of SCA solution, Core banking verifies the necessity to apply an exemption or to initiate SCA flow. As a result, the action is either executed or refused.
Core banking does not participate in enrollment flow.
Analyze and execute payment order data
- Analyze the incoming request for action initiation. It is necessary to analyze the type of action initiation - it might be either access request (AIS), payment initiation (PIS), or any other type.
- Verify whether SCA has to be initiated. Check whether an exemption has to be applied, or the action requires strong customer authentication.
- Generate ‘authorization_code’, linking it to the specific payment amount and the specific payee of the transaction (for payment initiation).
- Transform action/payment data into the convenient for customer message with ‘title’ and ‘description’.
- Send request to Identity Service to initiate SCA, providing ‘authorization_code’, ‘title’ and ‘description’.
- Receive result of SCA.
- Execute action/payment.