Improving the Customer Experience with Client Initiated Backchannel Authentication (CIBA)

Mark Perry
APAC CTO & Principal Architect

---

More than ever, today’s consumers expect an elegant experience when interacting with your business, especially when those exchanges take place in the digital space. These expectations are only increasing as consumers transact in the Open Banking world. From mobile banking to online purchasing to the use of third-party financial data aggregators, your customers expect control over how and when they share their personal financial data. They desire the controls to release their data, to whom, and to manage which third parties have access to their data over the lifetime of their relationship with them.

For enterprises that want to improve the end-user experience during authentication and authorization, a new technical specification is designed to help you do exactly that. Client Initiated Backchannel Authentication (CIBA) is an extension to OpenID Connect, the open federated identity standard for single sign-on (SSO) that enables seamless access to SaaS, mobile, cloud and enterprise applications. Of particular importance to financial services enterprises and financial technology companies but holding the promise of innovation across multiple industries, CIBA is gaining steam worldwide—and Ping Identity now supports this important extension.

What is Client Initiated Backchannel Authentication?
CIBA is a new specification written in part by Ping’s own Brian Campbell, developed out of the MODRNA Working Group of the OpenID Foundation. Like OpenID Connect, CIBA is an authentication flow, governing how clients are identified and granted access. But unlike with OpenID Connect, with CIBA there is direct Relying Party to OpenID Provider communication without redirects through the user's browser. In other words, this extension defines a new OAuth grant type where user consent can be requested through an out-of-band flow.

CIBA improves the user experience by streamlining how users give digital consent. For example, when a customer is making an online purchase from a merchant, the process doesn’t require a browser redirect to a financial institution to authorize the purchase. Instead, to complete the authorization, the user can receive a push notification sent to the financial institution’s native mobile app running on the user’s phone, allowing the customer to avoid confusing redirects via web browsers.

Here’s an example flow from the customer’s perspective, as illustrated by a purchase via a fictitious company’s website:

1. A consumer visits a merchant’s website and initiates a purchase.
   






2. The consumer opts to pay for their purchase via their bank. But instead of being redirected to the bank’s website, the user stays at the merchant’s website.
   






3. Moments later, the user sees a notification on their bank’s native smartphone app (made possible by a tool such as PingID SDK, which allows developers to embed secure identity services into their own applications).
   






4. The user opens the app, authenticates if necessary, and sees details of the attempted purchase.
   






5. The user approves the purchase, if desired, through the bank’s app. There may be an optional biometric step (e.g., TouchID, FaceID, etc.)
   






6. The user sees feedback through the web browser that the purchase has been completed, all without ever being redirected away from the merchant’s website.
   
   

   

   
   

PingFederate Support for CIBA
PingFederate, Ping’s authentication authority and federated SSO server, now supports such use cases in PingFederate version 9.3. On the back end, here’s what the decoupled flow actually looks like:

1. The Client makes a backchannel authentication request in the form of an "HTTP POST" request to the backchannel authentication endpoint (a new endpoint defined by CIBA) to ask for end-user authentication.
2. After receiving the request, the OpenID Provider (OP) responds immediately with a unique identifier that identifies that authentication while it tries to authenticate the user in the background. (This authentication process may take place on a smartphone, which passes the result to the authorization server.)
3. The Client then receives the ID Token, Access Token and optionally Refresh Token. PingFederate naturally supports both the Poll or Ping modes; this choice must be established by the Client at registration time.
   • Poll Mode: When configured in Poll mode, the Client will poll the token endpoint to get a response with the tokens.
   • Ping Mode: When configured in Ping mode, the OP will send a request to a callback URI previously registered by the Client with the unique identifier returned from the Backchannel Authentication Endpoint. Upon receipt of the notification, the Client makes a request to the token endpoint to obtain the tokens.

While here we’re not spelling out what happens at PingFederate/OP to interact with the user, as that is specific to each implementation, we expect the most common end user interaction will be via a push notification to the customer’s native mobile app.  

Open Banking and the Value of CIBA
Along with the aforementioned benefit of improving your end user experience by providing users with an option to consent via an out-of-band flow, CIBA has significant implications in the arena of Open Banking. Open Banking customers are able to stay ahead of evolving standards by deploying their CIBA solution, which standardizes the way users authorize a banking transaction in a secondary device. In Europe, CIBA allows banks to implement decoupled authentication flows outlined by PSD2 and UK Open Banking.

And now under the Consumer Data Right (CDR) of Open Banking in Australia, all financial institutions that hold customer accounts are required to provide open APIs that allow account data to be shared securely with third-party data recipients. Australia’s financial services institutions are on the path to adopting technology that enables them to expose and protect account data APIs in a security framework that prioritises consumer data rights, privacy and informed consent. While current frameworks are based on long-existing standards like OAuth 2.0 and OpenID Connect, currently CIBA is one of the standard data exchange flows being recommended as a future inclusion in the specification by the Advisory Committee. (It has been removed from the latest draft of v1.0, which is still going through reviews and is not final yet.)

At Ping Identity, we’re involved first-hand in guiding Open Banking worldwide. We’ve helped write the standards—Mark Perry, Ping APAC CTO, is the only vendor representative on the Australian CDR Advisory Committee, and Ping’s EMEA CTO, Rob Otto, works closely with both the Open Banking Implementation Entity and the OIDC FAPI group—and we intend to stay aligned with the industry and keep ahead of the curve. To learn more about what Ping is doing to help financial institutions prepare for compliance with major open API regulations, please visit our Australia Consumer Data Right page or our PSD2 & Open Banking page.