Contents

Summary

The v2.0 standard includes a decoupled authorisation flow, which provides a more customer and mobile friendly option for the customer to authorise consent (that has already been agreed between a customer and Third Party) with the API Provider. This does not replace the existing redirect model summarised below, but instead adds an additional implementation option.

Update for v2.2 (June 2022)

In v2.2 of the API Standards, the Decoupled Flow mechanism has been phased from Optional to Mandatory. This means that an API Provider supporting any version of the Standards after v2.2 must support the decoupled authentication flow function as summarised below and defined in the API Standard.

Redirect authentication flow

The redirect flow allows a customer to be transferred from the Third Party’s website or app, to the API Provider (the customer’s bank), and back again (once authentication and authorisation of consent have been completed). The redirect authentication flow is viewed as a secure and common way of authenticating a customer with an API Provider. This features in both v1.0 and v2.0 of the API standard.

Market feedback was that while the redirect flow has many benefits and is a mature process, the way it transfers or hands off a customer - from the Third Party, to their API Provider and back again - provides some customer experience friction and therefore constrained the usability of the v1.0 standard.

When a redirect flow is used, the customer must always use the same device, and must be on the Third Party’s website or app at the time authorisation is requested. While v2.0 retains this redirect flow functionality, it also adds a decoupled flow option (see below).

More information about the redirect authentication flow

• The current redirect model allows a customer to be redirected by a Third Party to an API Provider for authentication.

• The API Provider specifies their authentication link (URL).

• The Third Party registers their redirect link (URL) for the API Provider to redirect the customer back to the Third Party after authentication.

• Both API Providers and Third Parties may link native mobile apps to their URL (via deep/universal links).

• If a deep link is registered with an app, and the app is installed on the mobile device, the app will be opened.

• If the app is not installed, the mobile device opens the URL on the mobile web browser.

Implications of the redirect flow are:

• The customer must be redirected from the merchant’s website or app to their bank (API Provider).

• The customer will need to be present to authenticate themselves.

• Redirect only works if the customer interacts with a Third Party and an API Provider on the same device.

• The customer will need to let the Third Party know which API Provider to redirect for authentication.

Decoupled authentication flow

The decoupled flow separates the API Provider’s and Third Party’s respective interactions with a customer, making it possible for the API Provider to send the customer authorisation request notifications. It also makes it possible for the customer to interact with the Third Party and their bank (API Provider) on different devices for the same action. Decoupled flow functionality applies to both the Account Information and Payments Initiation APIs.

More information about decoupled authentication flow

The introduction of decoupled flow in the standard opens up a range of new use cases. For example:

• The customer does not always need to be present when a Third Party initiates a new authentication request.

• The interaction with the customer can occur on different devices or applications. The device the customer uses to interact with the Third Party does not have to be the same device used by the API Provider to authenticate the customer, (i.e. the Third Party interaction and API Provider’s authentication interactions are decoupled). For example, the customer makes a purchase at a merchant using a laptop, but authorises the transaction by interacting with their bank on their mobile phone.

• The API Provider can interact with the customer via different channels in order to get their authentication and authorisation (i.e. via text message, banking app, etc.).

The decoupled flow in the API standard is derived from the Open Banking Implementation Entity’s v3.x standard, which is in turn derived from the Financial-grade API Client Initiated Backchannel Authentication Profile (FAPI-CIBA) standard. FAPI-CIBA is a standard developed by the OpenID Foundation, an international technology standards group.

The decoupled flow model allows:

• A Third Party to send an API Provider an authentication request.

• The API Provider sends an out of band authentication request to the customer.

• The Third Party does not need to know how the API Provider authenticates the customer.

• The Third Party is notified by the API Provider that the customer has authenticated the request.

The implications of the decoupled flow are:

• The Third Party needs a way of identifying the customer to the API Provider, so the API Provider can send the authentication request to the customer. This means of identification must be registered with the API Provider (e.g. mobile number, customer login username).

• The customer must have an authentication device registered with the API Provider, for example, a mobile banking app.

• The customer needs to be present to authenticate themselves.