Making Open Banking Payments Simple with Decoupled Authentication
Back in July, my colleague Mark Perry wrote a blog describing how a new OpenID Connect specification called Client Initiated Backchannel Authentication (CIBA) can be used to improve the customer experience across a wide variety of interactions with an organization. Mark spoke about using CIBA’s Decoupled Authentication capabilities to streamline the process of authenticating customers and collecting their digital consent for various transactions, all without introducing browser redirections, a pattern that many customers find confusing.
In this blog, I’d like to pick up on what Mark wrote and expand further with a number of concrete use case examples, all in the realm of Open Banking digital payments. I used the capabilities of PingFederate (which fully supports CIBA as of version 9.3) and the PingID SDK to demonstrate a few alternatives that banks and other providers could build upon to offer both customers and merchant partners flexibility and choice in the payment approval process.
How Can CIBA Help with Open Banking?
Open Banking is the United Kingdom’s implementation of the European PSD2 legislation and is enabled and secured by a technical framework built on the OpenID Connect standard. The first version of the Open Banking Security Profile was based purely on a browser redirect model, as mandated by the OIDC FAPI specification. In this model, a customer would be securely redirected to their bank’s own authentication website in order to prove their identity and approve any payment transaction, before then being redirected back to the merchant to receive their order confirmation. While this approach is generally accepted to offer best-in-class security, feedback from actual customers over time has shown that it suffers from a number of usability concerns.
Customers have complained about the number of steps that are typically required to complete a payment and in a number of cases have opted to abandon transactions altogether due to the unexpected—and often confusing—redirections that take place. The model has proved even less popular with merchants, who bemoan the loss of control of the user interface and experience that the redirect pattern causes. The problems are only exacerbated when the customer is using a mobile device.
Taking this feedback on board, the Open Banking standards group, working closely together with the OpenID Foundation, has described a number of alternative approaches that banks and merchants can implement, utilizing decoupled authentication, and CIBA, to work around some of the aforementioned challenges.
Section 2.3 of the updated Open Banking Customer Experience Guidelines describes these decoupled flows in detail, but I’ll attempt to summarize some of the main options here, with the aid of a few simplified demonstrations.
Identifying the User is a Common Challenge
One of the more difficult problems to solve when using CIBA for decoupled authentication comes in identifying the correct user. In a redirect model, the merchant doesn’t ever need to know the user’s identity at the bank; this identification step is taken care of directly on the bank’s own site after the first redirect. In a decoupled flow, this isn’t possible, since the user is never redirected. Rather, the merchant needs to do something in order to provide the bank with a hint regarding the shopper’s identity. This should ideally provide as much protection of their privacy as possible; hence simply asking them to enter their Online Banking User ID is perhaps not the best approach!
The three scenarios below demonstrate alternative options for how this could be done. In each case, I’ll start with a quick video showing the journey that our mystery shopper (and AnyBank account holder), Angela, will experience when buying sporting apparel from the Limitless Ambition website. I’ll then go into a few details about each flow, hopefully without overwhelming technical specifics.
Option 1: Check Out with a One-time User ID
We start with a scenario where the shopper, Angela, has never previously used her AnyBank account to make a purchase with Limitless Ambition. In this case, she uses a specially generated one-time user ID to start the process. This one-time user ID is generated within her AnyBank mobile app, using a secure process between the app and the AnyBank back end. The one-time user ID is associated with Angela’s account and can only be used once; it’s up to the bank’s back-end infrastructure to maintain the association of that ID to Angela’s real identity.
Angela can safely provide this identifier directly to Limitless Ambition, and when the website starts the CIBA decoupled authentication flow to approve the payment, they send this one-time user ID to the AnyBank OpenID Provider as a login hint. AnyBank uses PingFederate, which allows them to de-reference the one-time user ID to determine Angela’s real user name via a simple API call, before using PingID SDK to send the payment approval message to the correct mobile phone.
This pattern may not necessarily offer the best user experience on a website, due to the need to generate and then type in a one-time user ID. If Angela were making a payment via a point-of-sale device, such as an in-store kiosk, though, it could be a lot more useful. In this case, the AnyBank app would display the one-time user ID as a QR code, which the kiosk could scan, rather than needing her to type anything.
Option 2: Check Out with a QR Code
An alternative to the approach above starts with the same precondition: Angela has never previously used her AnyBank account to make a purchase with Limitless Ambition. In this case, however, Limitless Ambition is going to generate a unique reference for the payment transaction and use that value as the login hint that it sends to AnyBank as part of the CIBA call. (Those familiar with the specifics of the Open Banking payment flows will no doubt realize that the merchant could use the Intent ID that the bank sends after payment staging as a ready-made, unique identifier for this purpose.)
In this case, Limitless Ambition encodes the unique reference in the form of a scannable QR code and displays it on their web page. Angela needs to scan this code with the AnyBank mobile app in order to approve the payment and complete her order.
What makes this flow a little unusual is that the merchant (Limitless Ambition) is not able to provide AnyBank with a login hint that identifies the user in any way. The login hint is merely a reference known to both parties and it is up to AnyBank to “figure out” who the user is after the fact. By scanning the QR code with her mobile app, Angela is able to claim the transaction. And, since her mobile app has her identity and also has the unique reference, it can now make a secured call to the AnyBank back end to associate her identity with that transaction reference, obtain additional details about the staged payment, and capture her consent and approval, prior to AnyBank releasing the appropriate tokens to the merchant.
Option 3: Use a Saved Identity Token
The third option is the most seamless of all from the shopper’s perspective, but does start with a different assumption. In this case, Angela has previously used her AnyBank account to pay for a purchase from Limitless Ambition, perhaps using one of the above flows, or even a previous redirect-based process. We can assume that Limitless Ambition has held on to the ID Token that it received from AnyBank during that process and has stored it safely in their own back-end directory, associated with Angela’s Limitless Ambition account.
Any time Angela now wishes to make a purchase from the site, Limitless Ambition can directly launch a decoupled authentication, passing this saved token as an ID Token Hint, as described in the CIBA specification.
AnyBank’s OpenID Provider, powered by PingFederate, is able to extract enough information from this previous ID Token that it is able to determine that the user is Angela, even if the ID Token itself does not contain her actual user name. PingFederate then uses PingID SDK to send a detailed transaction approval message to Angela’s mobile device, without her needing to do anything else.
Note that in all of the above cases, Limitless Ambition remains in full control of the end-to-end user experience without needing to ever redirect Angela’s browser away from their website.
Implementing Decoupled Authentication with Ping Identity
Through our work with the OpenID Foundation and our end-to-end solution for customer authentication and consent, Ping Identity is the perfect solution provider for enterprises wishing to improve customer experience using decoupled authentication and CIBA. While the above examples focus on banking and payments, we are brimming with ideas about how CIBA can add immense value to our customers in other industries too. Get in touch with us and let us show you how Ping Identity can make CIBA work for you.
