...
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 partyThird Party) with the API providerProvider. This does not replace the existing redirect model summarised below, but instead adds an additional implementation option.
...
The redirect flow allows a customer to be transferred from the third party’s Third Party’s website or app, to the API provider 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 providerProvider. 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 partyThird Party, to their API provider 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 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).
...
The current redirect model allows a customer to be redirected by a third party Third Party to an API provider Provider for authentication.
The API provider Provider specifies their authentication link (URL).
The third party Third Party registers their redirect link (URL) for the API provider Provider to redirect the customer back to the third party Third Party after authentication.
Both API providers Providers and third parties 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.
...
The customer must be redirected from the merchant’s website or app to their bank (API providerProvider).
The customer will need to be present to authenticate themselves.
Redirect only works if the customer interacts with a third party Third Party and an API provider Provider on the same device.
The customer will need to let the third party Third Party know which API provider Provider to redirect for authentication.
...
The decoupled flow separates the API provider’s Provider’s and third party’s Third Party’s respective interactions with a customer, making it possible for the API provider Provider to send the customer authorisation request notifications. It also makes it possible for the customer to interact with the third party Third Party and their bank (API providerProvider) on different devices for the same action. Decoupled flow functionality applies to both the Account Information and Payments Initiation APIs.
...
The customer does not always need to be present when a third party 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 Third Party does not have to be the same device used by the API provider Provider to authenticate the customer, (i.e. the third party Third Party interaction and API provider’s 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 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 model allows:
A third party Third Party to send an API provider Provider an authentication request.
The API provider Provider sends an out of band authentication request to the customer.
The third party Third Party does not need to know how the API provider Provider authenticates the customer.
The third party Third Party is notified by the API provider Provider that the customer has authenticated the request.
The implications of the decoupled flow are:
The third party Third Party needs a way of identifying the customer to the API providerProvider, so the API provider Provider can send the authentication request to the customer. This means of identification must be registered with the API provider Provider (e.g. mobile number, customer login username).
The customer must have an authentication device registered with the API providerProvider, for example, a mobile banking app.
The customer needs to be present to authenticate themselves.
...