App-to-App redirection

Based on user redirection, Strong Customer Authentication (SCA) can happen in two different ways:

Browser-based redirection
App-based redirection

Browser-based redirection is the general redirection flow supported by most of the open banking specifications. Certain specifications like Open Banking Standard - UK and NextGenPSD2XS2A - Berlin mention an app-based redirection flow known as App-to-App redirection.

WSO2 Open Banking supports both browser-based and app-based redirection flows.

Ideally, even when app-based redirection is used, browser-based redirection needs to be available for users who do not have the mobile application of the bank (ASPSP) installed in their devices.

According to the OAuth2/OIDC Authorization Code Flow, the bank customer is redirected from the TPP mobile application to the bank’s mobile application via mobile OS utilities. Upon successful authentication, the customer (PSU) is redirected back to the TPP mobile application with the authentication code.

The Open Banking Implementation Entity recommends App-to-App redirection as the preferred method of implementing SCA. Refer to the Implementing App-to-App Authorisation in OAuth2/OpenID Connect blog, to gain a further understanding of this flow. This link directs you to an external site and its content is not owned by WSO2.

Customer Experience Guidelines

The bank’s interface and redirection may vary according to the service it provides. The following section explains some guidelines provided by the Customer Experience Guidelines, Open Banking Standard - UK.

Account Information Service

If the TPP application is aggregating account information on behalf of the PSU, the APP-to-APP redirection flow is as follows:

According to Open Banking Standard - UK, when a TPP application provides the Account Information Service, it is known as an Account Information Service Provider (AISP).

According to the Customer Experience Guidelines, Open Banking Standard - UK, the following implementation steps are described explicitly:

Implementation	Requirement	Participant
A- AISP requests the PSU to identify the ASPSP	Required	AISP
B- The ASPSP app loads for the authentication (If the ASPSP app resides in the same mobile device, or else redirect to the browser)	Required	ASPSP
C- The PSU consents to the accounts, which the AISP is allowed to have access	Required	ASPSP
D- Confirms the completion of AIS request	Recommended	AISP

Payment Initiation Service

If the TPP application is initiating a credit transfer on behalf of the PSU, the App-to-App redirection flow is as follows:

According to Open Banking Standard - UK, when a TPP application provides the Payment Initiation Service, it is known as a Payment Initiation Services Provider (PISP).

According to the Customer Experience Guidelines, Open Banking Standard - UK, the following implementation steps are described explicitly:

Implementation	Requirement	Participant
A- PSU enters/selects the account associated with their ASPSP	Required	PISP
B- Shares the information to obtain PSU consent before initiating a payment	Required	PISP
C- The ASPSP app loads for the authentication (If the ASPSP app resides in the same mobile device, or else redirect to the browser)	Required	PISP
D- Display the minimum payment amount, currency, and payee account name to the PSU	Required	ASPSP
E- ASPSP app-based authentication must not be more than the number of steps the PSU would go through when directly accessing the ASPSP interface	Required	ASPSP
F- PSU needs to be directed back to the TPP’s interface, displaying successful payment initiation confirmation.	Required	PISP

How WSO2 Open Banking supports App-to-App redirection

WSO2 Open Banking supports the App-to-App redirection flow as follows:

The TPP application invokes the authorize endpoint, similar to a basic browser-based auth-code/hybrid redirect flow. When the bank’s mobile application is installed in the customer’s device with a deep link connected to this authorize request, the request is handled by the bank’s mobile application instead of the browser.

If the bank’s mobile application is not available in the customer’s device, the customer is taken through a typical browser-based flow.

Once the mobile application handles the customer authentication and consent, it obtains a callback URI. This is the URL to the TPP application. Using deep links, the bank application redirects the customer to the TPP application. Here, similar to the initial scenario, the callback URI is deep linked to the TPP mobile application. Using this, the flow continues from the bank’s mobile application to the TPP application again.

In the App-to-App redirection method, the flow should be handled in the bank’s mobile application as follows:

The bank’s mobile application is opened using the deep link.
The application invokes the /authorize endpoint to initiate the authorization flow. The response redirect is sent by an authenticator that is customized to the app-based flow.

You need to configure custom authenticators that address the requirements of both browser-based and app-based redirection flows. For more information, see Adding Custom Authenticators.
If this is not an error page or application callback redirect, the application can gain the authentication of the bank customer. For example, using biometrics.

Based on the user agent of the auth request in the adaptive authentication script, a mobile app-based flow can be detected. This states which authenticators need to be invoked in each scenario.
Once the authentication is provided, a /commonauth request has to be made. This is processed by the authenticator mentioned above. In a biometric scenario, since the verification happens in the mobile application, this request should guarantee non-repudiation and client identification. Given below is a sample request, modify the payload according to your requirements:
```
curl -X POST \https://<WSO2_OB_IAM_HOST>:<WSO2_OB_IAM_PORT>/commonauth \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'sessionDataKey=value&username=value&password=value'
```
- It is recommended to have a key pair for the mobile application. So that the response can be included with a signed JWT, which helps to identify the client with guaranteed non-repudiation.
Successful authentication prompts a redirection response to the consent page that contains sessionDataKeyConsent. This value is extracted and will be used in the next step.
The authorize/retrieve request has to be sent with the SessionDataKeyConsent. This is to retrieve the data that is required to display on the consent page.
After the user approves/denies the consent and selects the accounts, a PATCH authorize/persist request is made to persist the consent information.
Finally, if the persistence is successful, to complete the flow the /authorize endpoint is invoked. This results in a redirection to the callback URL of the TPP application, which is deep linked to the TPP application. Therefore, the customer is redirected to the mobile application of the TPP.