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/.

Consumer Data Standards API v1.2.0

Owned by Former user (Deleted)
Last updated: Oct 15, 2020 by Former user (Deleted)Version comment
7 min read

This document explains the flow of events related to the Consumer Data Standards API v1.2.0. 

Before you begin:

You need to deploy the following APIS.

  • Consumer Data Standards API in <WSO2_OB_APIM_HOME>/repository/resources/finance/apis/consumerdatastandards.org.au/1.2.0/consumer-data-standards-1.2.0.yaml file. See Deploying APIs, for instruction on how to deploy this API.
  • Consumer Data Standards Dynamic Client Registration API v0.1 to register an Accredited Data Recipient (ADR) application. See Dynamic Client Registration API v0.1.

Step 1 - Authorising account consents

The bank redirects the bank customer to authenticate and approve/deny application-provided consents.

 Click here to see how it is done

  1. Generate the request object by signing the following JSON payload using the supported algorithms.

    To configure the supporting algorithms:

    1. Open the <WSO2_OB_APIM_HOME>/repository/conf/finance/open-banking.xml file.

    2. Update the following configurations with the algorithm:

      <UK>
	<!-- The following configuration specifies the signature algorithms allowed in the DR requests.
        The JWTs signed in algorithms that are not in the following list, will be rejected. If the configuration
        is not present, no validation will occur and any algorithm will be passed through.
        Allowed values are:
            1. PS256
            2. RS256
        -->
	<AllowedInboundSignatureAlgorithms>
		<Algorithm>PS256</Algorithm>
	</AllowedInboundSignatureAlgorithms>
</UK>

    The scope claim is required to access the data available via an endpoint. See Consumer Data Standards Australia - Authorisation Scopes, for more information on Authorisation scopes.

    The refresh token is used to regenerate an access token. The sharing_duration claim in the request object defines the validity period of the refresh token. This is to limit the validity of the consent to the defined period.

  2. Run the following in a browser to prompt the invocation of the authorize API. Make sure you update the placeholders with the relevant values:

  3. You are directed to a login page. Log in with the credentials of a user that has a Subscriber role.

  4. If a secondary factor is required. For example, SMS OTP, provide the relevant values. Upon successful authentication, the user is redirected to the consent management page.

  5. Upon providing consent, the consumer is redirected to the callback URL of the ADR with the authorization code.

Step 2 - Generate user access token

In this section, you will be generating an access token using the authorization code generated in the section above.

 Click here to see how it is done

  1. The client_assertion is a JSON Web Token (JWT). Generate the client_assertion by signing the following JSON payload using the supported algorithms:

    The value of the aud claim should contain the same value as the Identity Provider Entity ID.

     Click here to view the Identity Provider Entity ID:
    1. Sign in to the Identity and Access Management console at  https://localhost:9446/carbon . 
    2. In the Main menu, go to Home > Identity > Identity Providers > Resident.
    3. View the value in Resident Identity Provider > Inbound Authentication Configuration > OAuth2/OpenID Connect Configuration > Identity Provider Entity ID. By default this value is set to  https://localhost:8243/token .

  2. Run the following cURL command in a command prompt to generate the access token as an ADR user. Use --cert and --key in the access token generation request, for Mutual TLS authentication. 

    curl -X POST \
  https://<WSO2_OB_APIM_HOST>:8243/token \
  -H 'Cache-Control: no-cache' -k \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --cert <TRANSPORT_PUBLIC_KEY_FILE_PATH> --key <TRANSPORT_PRIVATE_KEY_FILE_PATH> \
  -d 'client_id=<APPLICATION_ID>&grant_type=authorization_code&code=<GENERATED_CODE>&redirect_uri=<APPLICATION_REDIRECT_URI>&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<CLIENT_ASSERTION>'

    The response of the contains an access token and a refresh token as follows:

    {
   "access_token":"4f939510-4330-336a-a3d6-3cee7e9f50da",
   "refresh_token":"cedd647f-cb01-3112-bfea-3a5eb61d05a8",
   "scope":"bank:accounts.basic:read bank:accounts.detail:read bank:transactions:read openid",
   "id_token":"eyJ4NXQiOiJORFV3WldGbE16WmlZalV6WmpJeE5USTNZV0V4T0dWXmw",
   "token_type":"Bearer",
   "expires_in":3496
}

    The access tokens have an expiration period, once an access token expires, you need to regenerate it. Run the following cURL command to generate a new access token using the refresh token:

    curl -X POST \
 https://<WSO2_OB_APIM_HOST>:8243/token \
 -H 'Content-Type: application/x-www-form-urlencoded' \
 -H 'cache-control: no-cache' \
 -k --cert <PUBLIC_KEY_FILE_PATH> --key <PRIVATE_KEY_FILE_PATH> \
 -d 'grant_type=refresh_token&refresh_token=<REFRESH_TOKEN>&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<CLIENT_ASSERTION>'

Step 3 - Invoke Consumer Data Standards API

This section shows how to invoke the endpoints in the ConsumerDataStandards v1 API using a few samples. These requests use the access token generated in the step above .

GET /banking/accounts

The ADR is able to obtain a list of accounts that the consumer has authorised the ADR to access.

POST /banking/accounts/balances

The ADR is able to obtain balances for a specified list of accounts. The request body contains a list of account IDs to obtain balances for.

See Consumer Data Standards Australia - Banking APIs, for more information on all the available endpoints.