App to Browser Redirection

App-to-browser redirection – AIS

It is possible that a PSU using a mobile device does not have their ASPSP mobile app installed, or their ASPSP does not provide an app at all. In these instances, the TPP app will need to launch the native mobile browser in order to present the PSU with their ASPSP’s web channel to authenticate.

It is imperative in these circumstances that the browser channel has been optimised for mobile browser and device type. 

Browser-to-app redirection

Conversely, a TPP may be browser only, but this should not preclude a PSU from having their ASPSP app invoked if the PSU is using a mobile browser and has the ASPSP app installed on their device. In this situation, the TPP browser should invoke the app for authentication and following authentication, the PSU needs to be redirected back to the TPP browser.

If a PSU is using a desktop to access the TPP, then under the redirection model the journey will have to be completed on the ASPSP browser channel. Only with Decoupled authentication can the PSU use their app to authenticate in this situation.

3Effective use of redirection screens

The research has suggested that the messaging on the redirection screens serves to reassure the customer that they are in control and helps engender trust. For example, customers will be more willing to trust the process if they feel there is a partner (TPP or ASPSP) 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 customer is in control and taking the lead are key, as these are indications that the TPP or the ASPSP is working with or for the customer.

Error scenarios during redirection 

As per OIDC, there are 2 main scenarios when an error occurs at the ASPSP side during the authorisation process:

• Malformed Authorisation Request: The authorisation request may be malformed when submitted by the TPP. For example, it may include an invalid redirection URL, invalid parameters, 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 TPP’s end or even an attacker trying to act as a TPP. For safety (and as per the standards) the ASPSP must not redirect the PSU back to the TPP in such situations. The ASPSP must display an error message and stop the execution at this point. It is at the ASPSPs’ discretion to display to the PSU the message they find most appropriate for this error case, however an error message must be displayed.

  In this situation, TPPs do not receive a response back from the ASPSPs about the malformed authorisation request. Therefore, TPPs are not able to display any message to the PSU in this situation.

  The PSU relies completely on the ASPSP 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 authorisation request does not belong to PSU etc. In this case, the ASPSP must redirect the PSU back to the TPP and provide in the response the appropriate OIDC error message.

The ASPSP could potentially display an error message to the PSU before redirecting back to the TPP, but it is solely at their discretion. The TPP should check the OIDC error code and display additional messages to the PSU 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 guidelines in the case these error scenarios, will prevent occurrences of bad customer experience due to errors managed insufficiently.