Authentication Specification Enhances Open Banking Experience

Photo by Christiann Koepke on Unsplash

First published on The New Stack.

Open banking has accelerated the transition of traditional financial services to the digital world. Consumers now have significant financial freedom and can access their financial data stored at banks through third-party providers.

Within this context, delivering enhanced digital experiences that are secure, seamless, and “always-on” has become vital. A recent survey by Qualtrics states that 89% of firms that lead with customer experiences perform better than their competitors.

The ownership of consumer data is no longer a decisive factor. However, it is vital that fintech firms provide consumers with a smooth user flow focusing on convenience, usability and security. Recently, OpenID Connect introduced a new technical specification known as Client-Initiated Backchannel Authentication (CIBA) to overcome this challenge. Please refer to the specification here.

Tech teams need to consider an out-of-the-box solution to support CIBA to enhance the end-user experience during authentication and authorization.

To explain and provide examples, we will use WSO2 Open Banking 3.0 as an implementation technology.

Key Terms

Consumption Device (CD) 

A device that helps consumers to interact with a third-party provider’s (TPP) open banking services. This can be a browser-based web application offered by a payment or account service provider in the open banking ecosystem.

Authentication Device (AD)

A device that helps consumers interact with a bank’s authorization server (AS) to authenticate and authorize their identities.

Why CIBA?

OpenID Connect is one of the main specifications that open banking is built upon. Open banking allows a third-party provider’s application to initiate an authorization flow on behalf of consumers. A consumer is redirected to a bank’s authorization server, and then engages in authentication, authorization (consent), and is finally redirected back to the TPP application along with verifiable assertions for the process to proceed.

Fig.1 : A sample Open Banking Flow Diagram

Figure 1 shows a sample open banking flow based on OpenID Connect. It is mandatory for the consumer to interact with the consumption device to authenticate themselves with the bank’s authorization server and provide consent. In addition, this back-and-forth consumer interaction with the TPP and the authorization server is handled via HTTP redirects. However, browser redirects are highly vulnerable to attacks. If consumer interaction with the CD for authentication and authorization is handled via a different device (AD), it eliminates the need for HTTP redirects. This is where CIBA comes in.

Key Features in CIBA

Decoupled Authentication

As a general practice, a user must use the same device to authenticate and consume a service. However, with CIBA, the authentication process is decoupled. The consumption device that runs the third-party provider application initiates the backchannel request for authentication and authorization while the actual authentication and authorization is performed on a separate authentication device — which can be any smart device, such as a mobile phone, smartwatch and point-of-sale system.

Token Requesting Modes

CIBA defines three token request modes for the TPP application following consumer consent authorization.

• Poll mode: Once the response for the CIBA authentication request is received, the TPP application must continuously poll the bank’s token endpoint under rate-limiting conditions.
• Ping mode: Once the consumer provides authentication from their device, a notification is sent to the TPP application (consumption device) from the bank’s authorization server. Only then will the TPP application send a token request.
• Push mode: Once the consumer provides their authentication from the authentication device, a notification is sent to the TPP application from the bank’s authorization server with the token itself. As this comes with a high-security risk, this is restricted for use in CIBA implementations in the financial domain by the Financial-grade API (FAPI) – Client-Initiated Backchannel Authentication Profile.

Please note that WSO2 Open Banking currently only supports poll mode. Since support for ping mode is not mandated by FAPI, it will be considered for support in a future release.

The CIBA Flow Explained

Figure 2 shows a sequence diagram for the CIBA flow using WSO2 Open Banking 3.0. Some CIBA-related new features have been implemented to handle steps 2, 3, 8 and 9, whereas steps 4, 5, 6 and 7 are handled by a new decoupled authenticator, also called a federated authenticator.

Fig.2 : CIBA Sequence Flow Diagram

Let’s discuss a CIBA flow by using an example use case. Assume a consumer wants to make an online retail purchase and opts to pay via their bank. The transaction will follow these steps:

1. The TPP application, which provides the payment service for the online store, initiates the backchannel authentication request to the bank’s CIBA authentication endpoint.
2. The CIBA specification defines the endpoint for CIBA authentication, introducing a new grant type and a response type as well. At this point, the consumer’s browser (CD) is not redirected to the bank’s authorization endpoint and continues to stay on the online store’s web page.
3. After receiving a successful response with an auth_req_id as the reference, the TPP application starts polling the token endpoint if the mode is polling.
4. The consumer should receive a notification on their phone (AD) where the bank’s online banking application is installed.
5. This notification is asynchronously generated by the bank’s authorization server after responding to the backchannel authentication request from the TPP and sent to the consumer’s pre-registered device. The alert is included with the requested consent information to be displayed on the mobile application.
6. The consumer opens their app and verifies purchase details. Then, they either deny or grant consent by providing their biometric authentication, such as a fingerprint.
7. Based on the response received from the authentication device, the bank’s authorization server updates the authorization status of the consent. In addition, it responds with a token for the next token polling sent by the TPP application, if consent is granted.
8. Once this backchannel authentication process is completed, the consumer is shown the payment status on the online store’s website.

Benefits of CIBA Compliance in Open Banking

1. The ability for consumers to provide consent through an out-of-band flow that mitigates traditional website redirects.
2. The flexibility to share critical identity information in a secure manner.
3. Use of smart devices allows the integration of biometric technology. This helps to balance security with convenience and speed.
4. A bank’s future depends on using new technologies to deliver innovative and frictionless banking experiences. Achieving CIBA compliance significantly helps with this in a fast-changing, customer-centric banking ecosystem.
5. Satisfying customer experiences, with help from CIBA, will reward banks with loyalty, trust and strong referrals from customers.

We hope this post helps readers to understand more about CIBA and how this specification helps banks and financial firms to develop customer-centric solutions. To learn more, please visit our solution page.