
**CIBA is a Decoupling Flow that decouples the client application also known as Relying party and authentication server.**

We come across front channel authentication flows all the time, like [OAuth 2.0](https://www.miniorange.in/iam/solutions/oauth-single-sign-on-sso), [SAML](https://www.miniorange.in/what-is-saml) flows. For instance, when you try to log into YouTube. On clicking the ‘Sign In’ button, the request is sent to ‘accounts.google.com’ by browser redirect through the front channel. There you can authenticate yourself and grant access to YouTube. This is an example of Redirect Flow.

Redirect Flows work well for the scenarios where the client application and authentication server are on the same device.

Now, the question is – Are there any scenarios where the device on which client application is running, and the device on which the user authentication happens must be two separate devices?

### WHAT IS CIBA? {#what-is-ciba}

**CIBA** (Client Initiated Backchannel Authentication) is an extension to the traditional OpenID Connect flow. In CIBA there is a direct Relying Party(Client Application) to OpenID Provider communication without redirects through the user’s browser.

Put simply, The client application and the authentication server are on two separate devices – Decoupled . CIBA is a Decoupling Flow that decouples the client application and authentication server. The authentication server and the client application communicate via the backchannel (Server to server communication).

In CIBA, user interaction at the consumption device is not a necessity, unlike other redirection flows. CIBA itself can initiate the authentication flow for the specified user. Therefore, to authenticate, we do not need multiple browser redirects as in the case of Authorization code flow and implicit flow. 

### WHY WE NEED CIBA? {#why-we-need-ciba}
Let us understand this using an example –

For instance, you book an Uber. The cab arrives and takes you to your destination. As usual, you click on the ‘Pay using UPI’ button. It detects the UPI application on your device and redirects you to that application, let’s say Google Pay. You authenticate yourself by providing the UPI Pin and click on ‘Pay’. However, your account balance is low. Therefore, you call your friend and ask them to pay. But here the problem is we’re using a **redirect flow** i.e., as soon as you click on the ‘Pay’ button the Uber app redirects you to your banking app. Now how do you make it redirect to your friend’s app? the client application (Uber app) and the authentication server app (your friend’s Google Pay) have to be on the same device.

Now let’s consider the same scenario, but with the **decoupled flow** –

At the time of the payment, let’s suppose you are asked to enter the UPI ID. Instead of redirecting to the payment app, the UPI ID holder is notified to either make or decline the payment to the client application, Uber. In other words, there is no redirection. In this flow, you can enter your friend’s UPI and they will receive a notification like the one shown in the below image. And therefore, can make the payment using their device. Hence, as soon as the payment is done, the client application, Uber is notified. Voila!

![Example of Decoupled Flow](/blog/assets/2023/example-of-decoupled-flow.webp)

Considering the scenario above, *there is indeed a need to have decoupled flow*.

### CIBA WORKFLOW {#ciba-workflow}

To understand the workflow of CIBA properly, let us first look at this simplified CIBA flow image.

![simplified CIBA flow](/blog/assets/2023/simplified-ciba-flow.webp)

**Components in the flow** –

- **Client Application** – A third-party application that provides a service, for instance, Uber.
- **Authentication server** – The server on which end-user authentication and consent confirmation are performed, for instance, mobile phone.
- **Authorization Server** –  The server that issues the OAuth Client tokens to the client application, for instance, Google Pay Authorization Server.
- **User** – The resource owner whose interaction is needed at the authentication server, for instance, Payer

### UNDERSTANDING THE FLOW {#understanding-the-flow}

**1. Flow Initiation** – The client application and Banking Authorization server communicate via the backchannel. Therefore, the client application sends an HTTP POST request to the Banking authorization server.

![Flow Initiation](/blog/assets/2023/flow-initiation.webp)

**2. End-User Authentication and consent confirmation** – Upon receiving the HTTP request, the authorization server delegates the task of end-user authentication and consent confirmation to the authentication device.

![End-User Authentication and consent confirmation](/blog/assets/2023/authentication-and-consent-confirmation.webp)

**3. Issuing Tokens** – In CIBA flow, we do not need HTTP browser redirects to issue tokens to the client application because the authorization server and client application can communicate directly via the backchannel.

![Issuing Tokens](/blog/assets/2023/issuing-tokens.webp)

In CIBA, there are three flows after consent confirmation. They are called **POLL mode**, **PING mode**, and **PUSH mode**. An ID token, an access token, and optionally a refresh token are issued in every flow.

- **POLL mode** – In POLL mode, after getting a response from the backchannel authentication endpoint, **the client repeats token requests** (polling) to the token endpoint. If the process on the authentication device has not finished yet, the token endpoint returns ‘400 Bad request’ with JSON including “error”:” authorization_pending”. Therefore, the client repeats token requests until it receives the tokens or gets a time-out error.
- **PING mode** – In PING mode, the authorization server sends a notification to the **client notification endpoint** after the process on the authentication server is complete. After that, the client application makes a token request to the authorization server.
- **PUSH mode** – In push mode, when the processing on the authentication server is completed, the **authorization server generates the id_token, access_token**, and refresh_token (optional) and delivers it directly to the client notification endpoint. Therefore, the client application doesn’t need to make a token request.

### CIBA USE CASES {#ciba-use-case}

- When the user can not trust the relying party (client application) and therefore, cannot create a session in their browser to give authorization. Eg. The sales terminal at the shopping center. To pay at the shopping mall, you wouldn’t want to create your banking session on their device, for instance. Rather, you’d prefer to receive some OTP and authorize that transaction from your own device because you don’t trust the client application.
- When the user doesn’t have access to the relying party. Eg. The cases similar to the example we gave above. Where your friend doesn’t have access to your Uber app and still wants to authorize the transaction. 
- When the relying party doesn’t have a browser, eg. IoT. If you want to switch ON the microwave (relying party) from your device.

### CONCLUSION {#conclusion}

In conclusion, for all the above usecases, the common thing is that we have **strongly authenticated session**s on our mobile devices. 

**The only limitation is – we can’t have those sessions in the relying party.**

What if we want to authorize another device, then we need to create an authentication session on that device. But what if we can just bypass all of that. Especially, in the case of banking applications. 

### RESOURCES AND FURTHER READING {#resources-and-further-reading}

- [OAuth APIs in miniOrange](https://developers.miniorange.in/docs/idp/api/oauth-api)
- [OpenID API guide](https://developers.miniorange.in/docs/idp/api/openid-api)
- [miniOrange Identity Provider- SSO, MFA, Adaptive Authentication, and much more.](https://www.miniorange.in/)

In CIBA, the client application and authentication server are 2 separate devices - Decoupled. They communicate via the backchannel.

CIBA – An Introduction To OpenID CIBA


## What is open banking {#What-is-open-banking}

The advent of digital marketplaces, eCommerce, and smartphones has paved the way for Open Banking to become ever popular. Open banking refers to when financial institutions share their customer’s data with each other via APIs to integrate their services. It grants consumers the flexibility to make transactions and invest their money on a global scale. However, it also opens a new set of challenges and risks that must be addressed.

Open Banking can also involve sharing customer data over APIs with third-party developers that build a web or mobile applications. These applications can facilitate the banking services provided by FinTech companies, bringing value to the customer experience. As such, greater financial transparency and trust in data protection become a priority for these users.

### What is FAPI? {#What-is-FAPI}

[Financial-grade API](https://www.example.com) or FAPI, is a set of standards and regulatory guidelines to protect sensitive customer data and prevent bad actors from manipulating it. Since financial records and personal details of users are being shared by organizations via APIs, there needs to be some form of accountability to keep them in check. FAPI is just that.

Besides this, if you’re involved in financial activities in the European Economic Area (EEA), you also need to adhere to the [Payment Services Directive (PSD2)](https://www.example.com). It is a regulatory requirement that further protects customers and their assets from fraud or illegal online activity.

Strong Customer Authentication (SCA) is a requirement of the Payment Services Directive. It is like the commonly known Two-Factor Authentication (2FA). It basically means that when a customer is performing a transaction online using their debit or credit card, they will be required to enter a secondary one-time password generated on their mobile banking application.

FAPI, however, isn’t just limited to the EEA. It is a protocol developed by the OpenID foundation and is built on the OAuth 2.0 and OIDC (OpenID Connect) frameworks. It aims to bring enhanced security to API standards for online transactions in various industries such as healthcare, insurance, telecommunications, etc. This is done thanks to four important factors:

- Any exchange of data between the client and server is via JSON Web Tokens (JWT).
- JWTs use asymmetrical key pairs to ensure cryptographic password exchange.
- The exchange of JWT allows a limited set of security algorithms.
- It offers conformance testing methods, which can be automated.

### Benefits of FAPI {#Benefits-of-FAPI}

**Strong level of authentication**
Clients can trust the authentication that includes mutual Transport Layer Security (TLS) and JSON Web Token (JWT) based mechanism that functions on the application level.

**Strengthen API security and reduce risk**  
Open banking financial providers require a top level of security to transfer data and transactional information to Fintech providers without risking intrusion. It needs to adhere to legal and regulatory standards and prove that the customer’s privacy and sensitive information are protected.

**Token-based data exchange**  
Enforcing the use of a signed JWT that is cryptographically encrypted increases the level of trust between the client and server. The cryptographic proofs are an optional feature in OpenID Connect.

**Seamless and simple to use**  
Adding stringent regulations and limitations often hamper the usability and profitability of services. But, FAPI balances it out by prioritizing a simple process for users while still having a robust and secure authentication system.

**Flexible to many industries**  
The banking-level security of FAPI using OAuth and OpenID Connect is available not just for financial providers. It can be used by just about any online service provider that deals with a sizable number of clients and customers that need their private information protected, yet easily accessible.

### Scope of FAFI {#Scope-of-FAFI}

As mentioned above, FAPI isn’t just limited to the banking sector. It can be used as a general standard for sharing sensitive information via APIs while guaranteeing client security. This is made possible by using one of the following four standards

**Read only API security profile**  
Read-only access, as the name suggests, only allows viewing the contents shared by the API, but not editing it. This can come in handy when one provider wants to verify the details of a user before confirming a transaction. It has a comparatively lower risk compared to the read-and-write access profile. Thus, applying a lower protection level is satisfactory. However, it contains sensitive information and must have a higher protection level than the basic OAuth level.

**Read & write API security profile**  
Read and write access to a bank’s API has a much higher level of risk, requiring a higher level of security as well. The OIDF Financial-grade API (FAPI) is a REST API that provides JSON data representing higher-risk information. This profile provides an ID token in response to the authorization request. However, it doesn’t always provide the identity of the resource owner. It may be used as an identifier for a time-limited subject that wishes to change user data.

**JWT secured authorization response mode for OAuth 2.0 (JARM)**  
 This profile features a JSON Web Token (JWT) that carries various data points to secure the transmission. The URL of the issuer that created the response, the client ID for whom the response is intended, and the expiration date of the JWT. Together, these parameters really amp up the security of the profile for OAuth 2.0. They are present in the token even in case of an error response. And since it has an expiration date, it cannot be misused by unauthorized users on the same system.

**Client initiated back channel authentication (CIBA) profile**  
This profile applies to both read-only and read-and-write APIs. Client-Initiated Backchannel Authentication, or CIBA, extends OpenID Connect to a decoupled flow where authentication can be started on one device and carried out on another. It enables direct communication between the client and the authorization server. All the above essentially hardens the level of security offered by OAuth and OIDC. Additionally, CIBA offers a new method of requesting the authentication of an end user. Therefore, FAPI essentially closes out loopholes and toughens up OAuth and OIDC processes, making them fit for a practically limitless number of industries. Since OAuth and OIDC are so widely used, industries like healthcare, education, eCommerce, telecommunications, FinTech, insurance, etc. must conform to the standards of FAPI. All such industries necessarily need to adapt to growing markets, increasing competition, and an expectation of swift provision of services without compromising on security. FAPI helps you get there.


The Financial-grade API  protocol is a set of standards and guidelines that aim to ensure the security and reliability of APIs  used in the financial industry. APIs are a way for different software systems to communicate and exchange data. FAPI provides a framework for financial institutions to develop and implement APIs that meet certain security and privacy requirements. 

CIBA – An Introduction To OpenID CIBA

What is Financial-grade API protocol and Open Banking?