This space is deprecated and no longer supported. Please use the latest available version here.
Authentication by LFI
- Chris Michael
- Alexandros Dimitrakoudis
- Warren Handley
1. Overview
This section covers redirection, decoupled redirection supported by the UAE Open Banking Standard (the Standard) to allow a User of a TPP to use the same authentication mechanisms as they do when accessing their LFI directly.
The general principles relating to the authentication models in this section that apply are:
LFIs authenticate: The User MUST go through Multi-Factor Authentication (MFA) at their LFI for a User-facing TPP request (i.e. Service Initiation or Data Sharing) to be actioned by the LFI.
Availability of normal authentication methods: The User MUST be able to use the elements they prefer to authenticate with their LFI if supported when interacting directly with their LFI.
Not replicating online journeys: The LFIs online channels may require doing an MFA multiple times, once for the User to login and then for any additional activity like adding new beneficiaries. However, for an Open Finance journey, the User MUST go through an MFA with the LFI only once before they authorize the consent. There should be no additional authentication required.
No Obstacles: LFIs MUST not create unnecessary delay or friction during authentication including unnecessary or superfluous steps, attributes, or unclear language, e.g. advertising of LFI products or services, language that could discourage the use of User-facing TPP services or additional features that may divert the User from the authentication process.
2. Redirection
Redirection-based authentication has a range of possible experiences for a User based on whether the User has an LFI app or not and the device on which the User is consuming the User-facing TPP service.
When using a User-facing TPP for Data Sharing Requests(DSR) and Service Initiation Requests(SIR) Users MUST be able to authenticate with the LFI using the same authentication methods they are accustomed to using when accessing the LFI directly.
We have used one example of a User-facing TPP and DSR journey to demonstrate how a redirection flow MUST work. (The same applies to SIR and service requests)
2.1 App-to-App
User authentication with the LFI using the LFI mobile app installed on the same device on which the User is consuming the User-facing TPP service. The User starts the journey from a User-facing TPP app.
2.1.1 User Journey
2.1.2 Customer Experience
A prototype of this journey showcasing a Personal Finance Use Case can be found here https://www.figma.com/proto/dGPBDz7AXnVmzUFdoUKk8Q/Prototypes?node-id=1-2&t=yWHex5k7pBpeeisc-1&scaling=scale-down&content-scaling=fixed&page-id=0%3A1&starting-point-node-id=1%3A2
This enables the User to authenticate with the LFI while using a User-facing TPP for an Open Banking services (i.e. DSR, SIR, & Service Request) using the same LFI app-based authentication method which they use when accessing the LFI mobile channel directly.
User-facing TPP service COULD be web-based or app-based. The redirection MUST directly invoke the LFI app to enable the User to authenticate and MUST not require the User to provide any User identifier or other credentials to the User-facing TPP.
To demonstrate an app-based redirection part of the journey, we have used the User-facing TPP initial setup as one example.
Rules & Guidelines | |
|---|---|
| 1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs data group and/or service initiation capabilities. |
| 2 | User-facing TPPs SHOULD make the User aware on the inbound redirection screen( User-facing TPP to LFI) that they will be taken to their LFI for authentication for data sharing. |
| 3 | If the User has an LFI app installed on the same device the redirection MUST invoke the LFIs app for authentication purposes only without introducing any additional screens. The LFIs app-based authentication MUST have no more than the number of steps that the User would experience when directly accessing the LFI app (biometric, passcode, credentials) and offer the same authentication method(s) available to the User when authenticating in their LFIs direct channels |
| 4 | After authentication, the User MUST be deep linked within the app to confirm the account(s) to which they would like the User-facing TPP to have access. |
| 5 | Invoking of the LFI App will happen only if the User has not chosen to block being redirected to the app. If the User has blocked redirection to the app then the User will be redirected to a browser-based authentication and authorization journey of the LFI. |
| 6 | LFIs SHOULD have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
| 7 | LFIs SHOULD inform the User on the outbound redirection screen that their session with the LFI was closed. |
| 8 | User-facing TPPs SHOULD confirm the successful completion of the Open Banking Service Request (DSR, SIR). |
2.2 Browser-to-App
Conversely, User-facing TPP may be browser-based only. However, if the User:
a) is using a browser on a mobile device and
b) has the LFI app installed on their device
then the User-facing TPP website MUST redirect the User’s browser to the LFI. The LFI on receiving the redirection request MUST invoke the LFI app for authentication on the User’s device. Following authentication, the User MUST be redirected back to the User-facing TPP browser on the mobile device.
2.3 Browser-to-Browser
If a User is using a desktop browser to access the User-facing TPP, then under the redirection model the journey MUST be completed on the LFI browser channel.
Browser-to-browser redirection is also applicable when:
a) the user-facing TPP is browser-based only
b) the User is using a browser on a mobile device and
c) the mobile device does not have the LFI mobile app installed, or the LFI does not provide an app at all.
It is imperative in these circumstances that the LFI browser channel has been optimized for mobile browsers and device types.
The following alternative experience MUST be implemented by LFIs to allow customers to use their mobile banking app to complete Authentication and Authorization:
The LFI MUST support a web-based landing page that opens on redirection with a Call to Action (CTA) to trigger an interaction using the User’s mobile banking app.
The CTA provided on the page must be:
For non-mobile devices, a QR Code that can be scanned by the User. Direction must be displayed that indicates to the User that they must scan the QR Code with a device that has the LFI app installed.
For mobile devices without the LFI app installed, a CTA that enables the User to download the app from the relevant app store.
The QR Code displayed MUST be scannable directly by any mobile device camera and resolve into a deep link which will invoke the LFI mobile app on that device. The deep link will result in the User being prompted to complete Multi-Factor Authentication and be presented with a screen that allows them to complete consent authorization.
Where the CTA results in the User installing the LFI mobile app, the LFI must inform the User that they may have to reinitiate the request from the TPP, as the delay introduced in installing and setting up the LFI app is likely to expire the authorization window set by the TPP.
The LFI MUST provide the means for the User to abandon handoff to a mobile device and instead choose to complete Authentication and Authorization using the LFI web channel, where supported.
2.3.1 User Journey
2.3.2 Wireframes
Rules & Guidelines | |
|---|---|
| 1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs data group and/or service initiation capabilities. |
| 2 | User-facing TPPs SHOULD make the User aware on the inbound redirection screen(User-facing TPP to LFI) that they will be taken to their LFI for authentication for data sharing. |
| 3 | The redirection MUST take the User to the LFI web page (desktop/mobile) for authentication purposes only without introducing any additional screens. The web-based authentication MUST have no more than the number of steps that the User would experience when directly accessing the web-based LFI channel (desktop/mobile). |
| 4 | After authentication, the User MUST be deep linked within the app to confirm the account(s) to which they would like the User-facing TPP to have access to. |
| 5 | LFIs SHOULD have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
| 6 | LFIs SHOULD inform the User on the outbound redirection screen that their session with the LFI was closed. |
| 7 | User-facing TPPs SHOULD confirm the successful completion of the Open Banking Service Request (DSR, SIR). |
2.4 App-to-Browser
It is possible that a User is using the User-facing TPP app on a mobile device which does not have their LFI mobile app installed, or their LFI does not provide an app at all.
In these instances, the User-facing TPP app MUST redirect the User to use the default mobile browser to present the User with their LFI's web channel to authenticate.
The browser for the User authentication MUST not be an embedded view within the User-facing TPP app.
Again, in these circumstances, it is imperative that the LFI browser channel is optimized for mobile browsers and device types.
A prototype of this journey showcasing a Personal Finance Use Case can be found here https://www.figma.com/proto/dGPBDz7AXnVmzUFdoUKk8Q/Prototypes?node-id=6098-1148&t=GOLXcgPJTAzkLids-1&scaling=scale-down&content-scaling=fixed&page-id=6061%3A412&starting-point-node-id=6098%3A1148
3. Decoupled Redirection
In “Decoupled” authentication, typically the User uses a separate secondary device to authenticate with the LFI. This model allows for several innovative solutions and has the added benefit of allowing a User to use their mobile phone to authenticate taking advantage of biometrics for MFA, where they are engaging with a User-facing TPP through a separate device, such as a desktop/laptop of a point of sale (POS) device.
In a Decoupled Redirection flow, the User uses a deeplink within the User-facing TPP app/website on one device to invoke their LFI app/website on another device using the same redirection mechanism as in Authentication by LFI | 2. Redirection
The following User experiences are available using Decouple Redirection:
3.1 Selection of LFI on the First Device
An authentication flow in which a dynamic link (e.g. via a QRCode or NFC) is generated by the User-facing TPP on one device (e.g. desktop/laptop or kiosk) and is scanned by User on another device (e.g. User’s mobile device). This dynamic link will invoke the LFI’s mobile banking app which uses the information from the dynamic link to then redirect the User to process the request after authenticating the User.
This journey does not introduce any changes in the redirection flow between the User-facing TPP and the LFI.
3.1.1 User Journey
3.1.2 Wireframes
To demonstrate a Redirection flow on different devices, we have used one variation of the DSR journey as an example where the LFI receives all the details of the request from the TPP.
We have illustrated an example where the dynamic identifier is a QR code. The code SHOULD contain a DeepLink (as within the Redirection flow) supported by the LFI which SHOULD invoke the LFI app when the User scans the QRCode.
Rules & Guidelines | |
|---|---|
| 1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs data group and/or service initiation capabilities. |
| 2 | User-facing TPPs MUST present Users with the authentication options supported by the LFI which in turn can be supported by the User-facing TPP device/channel (e.g. A User-facing TPP kiosk that can only support authentication by LFI mobile app). |
| 3 | The User-facing TPPs MUST display a code which is scannable or readable ( QRCode/NFC) by another User device. The User-facing TPP MUST present the information on how to use the code with their mobile device (e.g. scan QR code with the mobile phone camera). NOTE: The QRcode MUST be a deep link (as within the Redirection flow) supported by the LFI which MUST invoke the LFI app on scanning. |
| 4 | User MUST be able to easily scan the code (e.g. scan the code from the Kiosk in this instance) without much friction (like manually entering any URLs). |
| 5 | After the User scans the code from the User-facing TPP with a device camera, the LFI app MUST be invoked to perform the MFA. |
| 6 | The LFI app-based authentication MUST have no more than the number of steps that the User would experience when directly accessing the LFI mobile app (biometric, passcode, credentials). |
| 7 | LFIs SHOULD have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
| 8 | LFIs SHOULD inform the User on the outbound redirection screen that their session with the LFI was closed. |
| 9 | For this experience it is essential that the User-facing TPPs MUST have a web page where the LFI can redirect the control back to the User-facing TPP on the second device. The User-facing TPP must confirm on this mobile web page the successful completion of the request and informs the User to continue on the other device(Kiosk/desktop) where they had started their journey. |
3.2 Selection of LFI on the Second Device
This journey is a variation of the User-facing TPP flow within the standard redirection journey which could be triggered from a non-interactive interface of the User-facing TPP (e.g. advertising board) which then progresses on the User’s mobile device. The LFI selection and consent request happens on the User's mobile device which then invokes the LFI app/webpage on the same device to complete the authorization using a redirection flow.
This journey does not introduce any changes in the redirection flow between the User-facing TPP and the LFI.
3.2.1 User Journey
3.2.2 Wireframes
To demonstrate a Redirection flow on different devices, we have used one variation of the DSR journey as an example where the LFI receives all the details of the request from the TPP.
We have illustrated an example where the static code on an advertisement board is a QR code. The code SHOULD contain a deepLink supported by the User-facing TPP which SHOULD invoke the User-facing TPP app/webpage on scanning.
Guidelines | |
|---|---|
| 1 | The Call to Action (CTA) COULD be a static QRCode/NFC tag. Scanning of the static code by the User SHOULD invoke a User-facing TPP page/app deep linking them to the service represented by the code. |
| 2 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs data group and/or service initiation capabilities. |
| 3 | User-facing TPPs SHOULD make the User aware on the inbound redirection screen(User-facing TPP to LFI) that they will be taken to their LFI for authentication for data sharing. |
| 4 | If the User has an LFI app installed on the same device the redirection MUST invoke the LFIs app for authentication purposes only without introducing any additional screens. The LFIs app-based authentication MUST have no more than the number of steps that the User would experience when directly accessing the LFI app (biometric, passcode, credentials) and offer the same authentication method(s) available to the User when authenticating in their LFIs direct channels |
| 5 | After authentication, the User MUST be deep linked within the app to confirm the account(s) to which they would like the User-facing TPP to have access. |
| 6 | LFIs SHOULD have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
| 7 | LFIs SHOULD inform the User on the outbound redirection screen that their session with the LFI was closed. |
| 8 | User-facing TPPs SHOULD confirm the successful completion of the Open Banking Service Request (DSR & SIR). |
4. Effective Use of Redirection Screens
Within a typical redirection journey, a User is presented with two redirection screens:
The redirection screens are a useful part of the process, providing User trust. The following reasons are noted:
The messaging on the redirection screens serves to reassure the User that they are in control and helps engender trust. For example, Users will be more willing to trust the process if they feel there is a partner (User-facing TPP or LFI) on their side that is known and reputable (use language such as ‘we’, ‘our’). In this sense, the use of words that indicate that the User is in control and taking the lead is key, as these are indications that the User-facing TPP or the LFI is working with or for the User. |
|
5. Error Scenarios During Redirection
As per OIDC, there are 2 main scenarios when an error occurs at the LFI side during the authorization process:
Malformed Authorization Request: The authorization request may be malformed when submitted by the User-facing TPP. For example, it may include an invalid redirection URL, invalid parameters, an invalid signature on the request object etc. OAuth2 and OIDC define a whole list of potential errors. These are abnormal situations which indicate a significant technical issue at the User-facing TPP's end or even an attacker trying to act as a User-facing TPP. For safety (and as per the Standard) the LFI MUST not redirect the User back to the User-facing TPP in such situations. The LFI MUST display an error message and stop the execution at this point. It is at the LFIs’ discretion to display to the User the message they find most appropriate for this error case, however, an error message MUST be displayed.
In this situation, User-facing TPPs do not receive a response from the LFIs about the malformed authorization request. Therefore, User-facing TPPs are not able to display any message to the User in this situation.
The User relies completely on the LFI to be notified about the occurrence of an error.
User interaction error: An error occurred during user interaction, for example, users click on cancel or are unable to validate their credentials, the debtor account in the authorization request does not belong to the User etc. In this case, the LFI MUST redirect the User back to the User-facing TPP and provide in the response the appropriate OIDC error message.
The LFI COULD potentially display an error message to the User before redirecting back to the User-facing TPP, but it is solely at their discretion. The User-facing TPP SHOULD check the OIDC error code and display additional messages to the User with further information messages.
Error responses are documented as below:
For OIDC: https://openid.net/specs/openid-connect-core-1_0.html#AuthError
For OAuth 2: https://tools.ietf.org/html/rfc6749#section-4.1.2.1
Please note that both of the above scenarios are strictly checked by the FAPI conformance suite from OIDF.
Following the above requirements in the case of these error scenarios will prevent occurrences of bad customer experiences due to errors managed insufficiently.
© CBUAE 2024
Open License and Contribution Agreement | Attribution Notice
Please try out our Advanced Search function.