This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

App-to-App redirection

Owned by Former user (Deleted)
Last updated: Apr 16, 2020
3 min read

Strong Customer Authentication (SCA) can be implemented using the redirect method, in which the Payment Service User (PSU) is redirected from the Third Party Provider's (TPP's) interface to the Account Servicing Payment Service Provider's (ASPSP's) authentication interface. The PSU will be redirected back to the TPP's interface upon successful authentication. App-to-App redirection is the method when this redirection happens in a mobile web browser or a mobile application. 

App-to-App redirection is a recommended way of implementing SCA according to Open Banking Implementation Entity.

The ASPSP’s interface and redirection can vary according to the service it is providing with.

  • Account Information Service

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

According to the Customer Experience Guidelines, the following implementation steps are described explicitly:

ImplementationRequirementParticipant

A- AISP requests the PSU to identify the ASPSP

RequiredAISP
B- The ASPSP app loads for the authentication (If the ASPSP app resides in the same mobile device, or else redirect to the browser)RequiredASPSP
C- The PSU consents to the accounts, which the AISP is allowed to have accessRequiredASPSP
D- Confirms the completion of AIS requestRecommendedAISP

  • Payment Information Service

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

According to the Customer Experience Guidelines, the following implementation steps are described explicitly:

ImplementationRequirementParticipant

A- PSU enters/selects the account associated with their ASPSP

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

  • How WSO2 Open Banking supports App-to-App redirection

Let’s now see how WSO2 Open Banking supports App-to-App redirection. 

The TPP mobile application invokes the /oauth2/authorize endpoint in WSO2 OB KM  for authentication and authorisation of PSU before sharing the account information or initiating a payment. The user gets a 302 response with a redirection URL in the location header of the web browser.

 Click here to see a sample request that can be used to invoke the oauth2/authorize endpoint...
curl -X POST \https://<WSO2_OB_KM_HOST>:<WSO2_OB_KM_PORT>/oauth2/authorize \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'hasApprovedAlways=false&sessionDataKeyConsent=value&consent=approve%2Fdeny&user=value'

The parameter descriptions are as follows:

ParameterDescription
hasApprovedAlways

The parameter lets the user permanently approve all future consents provided for non-open banking scenarios. 

For open banking scenarios, this parameter has to be false.

sessionDataKeyConsent

The sessionDataKey that is received as a query parameter in the consent page URL. 

example: https://<WSO2_OB_KM_HOST>:9446/api/openbanking/consent/v1.0.0/consent/data/e134a4dd-20b8-4354-ad3f-a618c224245c 

consent

The consent provided by the user. 

Possible values: approve, deny

userThe username of the currently authenticated user.

In App-to-App redirection, 

  1. The TPP mobile application loads the ASPSP mobile app via Deep linking for PSU authentication. So that the PSU enters the user Id and password to the sign-in page.

  2. Upon invoking the /commonAuth endpoint, WSO2 OB KM submits the entered-authentication information, checks the next authentication step (if available), and respond with the redirection URL to the next authentication step.

     Click here to see the sample request sent for the basic authentication step...
    curl -X POST \
  https://<WSO2_OB_KM_HOST>:<WSO2_OB_KM_PORT>/commonauth \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'sessionDataKey=value&username=value&password=value'

  3. At the completion of pre-configured authentication steps, the consent page is displayed to the user by invoking the GET /consent/data/{session-data-key} endpoint. The user's consent is then captured and persisted by invoking the PATCH /authorize/{consent-id} endpoint. For examples, see Integrate the bank's consent page.

These authentication steps can be configured using the instructions provided under Adding Custom Authenticators. Thereby, WSO2 OB KM will check the authentication steps associated with the ASPSP mobile app and respond with them to the ASPSP mobile application accordingly.