What’s the Deal with CIBA?
What is CIBA?
Client-Initiated Backchannel Authentication (CIBA) is a specification from the OpenID Connect Foundation that describes a decoupled authentication flow. Although not yet widely implemented, CIBA has been profiled by the Financial-Grade API (FAPI) working group and is being adopted by banking regulations across the globe. This momentum means that CIBA may soon become not only popular due to its features but also mandatory, especially for companies working with financial-grade solutions. While CIBA is helpful in some scenarios, it's no silver bullet. It is thus an excellent idea to understand the flow, its benefits, and its drawbacks.
Overview of the Flow
In front channel authentication, the type that we're probably most used to, the user is the one who both initiates and performs the authentication. The user is physically present in front of the device that needs authentication (the device running the OpenID Connect (OIDC) Relying Party (RP)) and the device on which authentication is performed. That's why we talk about a coupled authentication flow in this case — the user's presence couples the RP and the authentication device. These two devices will often be the same; for example, a browser on a desktop computer, where the user opens a web page, then signs in by providing their username and password. Even if parts of authentication are done on another device (for example, an authenticator app is used or a confirmation link sent to a mobile phone), still most of the interaction with the Authorization Server is done on the device running the RP.
In a CIBA flow, the authentication is decoupled; that is, the user only needs access to the authenticating device. They don't have to be physically in front of the device running the RP (which in CIBA is called the Consumption Device). What is more, the user is not responsible for initiating the flow. Instead, the Relying Party does that.
A common use case for a CIBA flow will be a user authenticating in a call center or a bank branch. Currently, the user usually has to answer some security questions to authenticate themselves on a call. With CIBA, the Call Center operator will initiate the authentication flow on their computer, and the user will get a notification on their phone to authenticate.
If you want to learn more about the flow, have a look at our Overview of CIBA and some technical details of a CIBA flow.
Where CIBA Shines
What is CIBA good for? Part of that answer is in the name of the flow — authentication. It is worth remembering that CIBA is an authentication flow. Although the specification talks briefly about obtaining user consent, I believe it is best at performing the authentication of a user, not granting authorization to resources. In the financial-grade profile for CIBA, consent is mentioned further. The profile says that the authentication request should contain information about the transaction, which can be verified by the user and used to tie the authentication to the concrete financial transaction. Still, the specification leaves the details to the implementers, and at Curity, we have created an SDK that allows for helpful consent even for CIBA flows.
In a CIBA flow, the Authorization Server needs a way to contact the user's device that will be used for authentication. As this will usually be the user's mobile phone, the user will need to have an application installed for the Authorization Server to contact. That makes CIBA especially useful for authentication performed by banks. Most users have their bank's app installed anyway, which can successfully be used for authentication made with CIBA. Other solutions may involve sending an authentication link through a text message or an email. This can solve the problem of requiring an app to be installed on the phone but can degrade the user experience and security of the solution — it can be harder to verify who really clicked on a link in an email.
CIBA is a perfect solution for scenarios where the user is not in front of the device that requires authentication. Situations mentioned before, such as when the user needs to authenticate in a call center or at a clerk's desk, are situations where there are currently no better standards to use. A similar scenario might be when the user wants to authenticate on a device with no input, e.g., a smart speaker. The user can ask the speaker to sign in, and the speaker can then use a backend service to contact the user's phone asking for authentication.
CIBA Shortcomings
A CIBA flow provides great opportunities when you need a decoupled authentication, but the flow has its shortcomings. One of them is that you must rely on the authenticator app if you need a complex authentication flow. For example, if you use a bank's Authorization Server and their app to verify a transaction, it will be hard to perform any multi-factor authentication unless the bank's app does it. Should you require any interaction with the user, you will have to make sure that the user can follow the authentication flow in a browser (so you would have to send them a link) or use your own authenticator app. This, of course, is not an unsolvable problem, but it can complicate the flow and require your company to maintain a proprietary authenticator app.
A CIBA flow requires a user hint to perform authentication. The Authorization Server must know which user it should try to contact to perform authentication. An obvious implication of this is that a user can't register an account during a CIBA flow unless some unstandardized solutions are used (e.g., an email or phone number is used as the login). Sometimes the user hint will be provided by the user (like in the call center scenario), but other times it might be more complicated to obtain it. For example, in the FAPI CIBA profile, there is an example of using CIBA to authorize a transaction at a Point of Sale (POS) system. To start this flow, the user would need an app that can provide the POS terminal with a secure user hint.
CIBA may look like a good way to perform authentication or authorization even when the user physically uses the Consumption Device. For example, a desktop web page may use a CIBA flow to complete a payment authorization without redirecting the user to another page. The user can stay on the shop's website and authorize the payment on their mobile phone. However, it's usually better for these scenarios to perform App2App authentication (when on mobile) or implement a Hypermedia Authentication API (HAAPI). HAAPI gives the Authorization Server much better control over authentication and authorization, which results in a more robust and secure solution. Have a look at the overview of HAAPI to learn more about the concept and see how it's implemented in the Curity Identity Server.
Conclusion
The Client Initiated Backchannel Authentication enables a standardized way to perform a decoupled authentication flow. It can also be used for authorization, but it requires additional work on top of the base specification. Though CIBA proves helpful in a variety of scenarios, remember that it's definitely not a flow "to replace them all." So, hold off throwing away your implementations of the authorization code flow.
If you want to learn more about CIBA and see it working in action, have a look at the overview of CIBA article and the Understanding CIBA webinar we hosted in June.
