This document explains the flow of events related to the Consumer Data Standards API v1.3
Step 1 - Authorising CDR Arrangement IDs
There are two ways to send request_object in the authorisation URL. Authorisation and pushed authorisation endpoints are used by the bank to redirect the bank customer to authenticate and approve/deny consents before a Data Recipient accesses account or transaction information. Let's see how it is done in WSO2 Open Banking...
Method 1: Send the authorisation details in the authorisation URL:
Authorisation endpoint uses request_object, which consists of authorisation details in the authorisation URL.
Click here to see how it is done
Generate the request object by signing the following JSON payload using the supported algorithms.
Run the following authorisation URL in a browser to prompt the invocation of the authorize API. Make sure you update the placeholders with the relevant values:
Once you run the authorisation URL, you are directed to a login page.
- Log in with the credentials of a user that has a
Subscriber
role. - If a secondary factor is required. For example, SMS OTP, provide the relevant values.
- Upon successful authentication, the user is redirected to a page where the user needs to select the accounts that need to be authorised.
- Then confirm or deny the access to displayed details in the selected account(s).
Upon agreement, the consumer is redirected to the callback URL of the ADR with the authorization code. For example:
https://www.google.com/redirects/redirect1#code=2c8a03f7-af33-326f-839a-63a4eebfe3f5&id_token=eyJraWQiOiJEd01LZFdNbWo3UFdpbnZvcWZReVhWenlaNlEiLCJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiUlNBMV81In0.KaRhQA63F2Sm72zSZrkoRucIiz4IC0pzqApjTzSOJSyV_J6fYBwHuIAjLn4MZA36ZfVCmm3-KzqJcGAv9W9sDWBi7aI80CVKLFVJ2rh9l_9bMnANjm5fCsZ-pE_F4eW5BnqiU7xOoel31W2WF2brEWf9l5dibILU5E7inYKkQ9qPCS3Ei7uo9LTYQMWR4RQSglAsb5TsnijOPtGBvQgyuwOeI9vWBIcm7Y64NXuWKiv1iManbTepggpKhCSj9qPPizVV4v7Vv1IgHbvViRCE0uIvomLsL9qTxkBVK2s_h3welM9-9CE0WvoGkbYgsDc3nBQEx7Vj4hBiYJ0nD2_dWw.zslxDgOETvBaMOTQ.XAPYdrt5HXhvF53llXp40YkRHWBSrosYDc0UVLnqwJkAcNs3CQo8vWKSNqfc8l6CezvFPinul4LEp-eRrOqrpnhzAMf-W4O-s0jjF0dPsa3NII_qdi5bmCQhwxTVzo31SBiKn1aCBu8lQXSLUAz7z3UF6JyH1OkCXU3Ld8puF45QTRoTRPru8oNy8W8ZbchDj11IhEzrT9RPmWznCDQ3rs8M16R636-TuULXdSqJUGtXB3wteXu8lcgGpIMno1T6Bq2rI8Ncg_rCe6RgepAlEjlC0J0hpgMOk-EiXFDXN5N0NfEo6VSv9-M1v5THSJBThZIlcZrL-njz4G2NiDa30PSrQFqLgusYpZNpL1bHGsUbz_Xqvwlpjq-A5TcrqjxwWHkK383pY-tE064FKQuk93HnOee1gp4iRc9GLiqOK4vawSKStaSWe1oWxeFkDDuY85H3rFL1U8JzAC-vbPpozju82q7mONQto0q1fnCa80jtl5rDVsxzXLkEDbfwrvE-_13MKTLGc9io-PbEy6UgD9bAz5qvoOtNLWh0rcAbT5yhnZnruecB9l3yBsnbo60HQC_83mMzPWjGQaTm-ujO-hockrUSkezEO2JhNKrMWI5V-2aBNin_0UcSShMQnFy4P9baFKcyvrt2r3LNOvqfl_mK9qh57AOQw4vjhJRRaPVVacB8h5WCoiq8ut8wnHq3L2MvF9HId9T0Ug9FaPP76ofLziM.u19pyEql02PpVrFrki3RWA&state=af0ifjsldkj&session_state=c57cc0825bf8838fd2b6f14597ed34b5d9404493b216092e9daa766749cdac40.-1D9AEiTjPN-3hzlRFN97Q
- The authorization code from the above URL is in the code parameter (
code=4489572f-83c9-3589-b403-c4ecf8fb77f4).
Method 2: Send the authorisation details as a reference in the authorisation URL:
Unlike in the Authorisation endpoint, in the Pushed Authorisation endpoint, Data Recipients pushes authorisation details directly to the authorisation server and obtains a reference. The reference is notated by the claim; request_uri
.
Thereby, it prevents:
- Intruders from intercepting the authorisation information sent in the
request_object
- Authorisation request calls becoming large with the authorisation details signed in the JWT
and protects the confidentiality and integrity of the authorisation details when passing through a third-party application. Let's see how it is done in WSO2 Open Banking:
Click here to see how it is done...
- Configure
<WSO2_OB_IAM_HOME>/repository/conf/deployment.toml
as follows:To resolve authorisation request calls with request_uri,
a new request object builder must be added as follows:
[[oauth.oidc.custom_request_object_builder]]
type = "request_uri_param_value_builder"
class = "com.wso2.finance.open.banking.identity.extensions.builders.RequestUriRequestObjectBuilder"
By default, the expiry time of the request_uri
is set to 60 seconds. If you need to change the value, use the sample configuration as follows:
[open_banking.au.push_authorisation]
expiry_time = "60"
Add the following configuration to have the Data Holde identifier in the response under the request_uri
parameter:
[open_banking.au]
holder_identifier = "abc-bank"
Data Recipient shares the authorisation details with the authorisation server as a signed JWT and obtains request_uri
in the response:
Run the following authorisation URL in a browser to prompt the invocation of the authorize API. Make sure you update the placeholders with the relevant values:
- Once you run the authorisation URL, you are directed to a login page.
- Log in with the credentials of a user that has a
Subscriber
role. - If a secondary factor is required. For example, SMS OTP, provide the relevant values.
- Upon successful authentication, the user is redirected to a page where the user needs to select the accounts that need to be authorised.
- Then confirm or deny the access to displayed details in the selected account(s).
Upon agreement, the consumer is redirected to the callback URL of the ADR with the authorization code. For example:
https://www.google.com/redirects/redirect1#code=2c8a03f7-af33-326f-839a-63a4eebfe3f5&id_token=eyJraWQiOiJEd01LZFdNbWo3UFdpbnZvcWZReVhWenlaNlEiLCJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiUlNBMV81In0.KaRhQA63F2Sm72zSZrkoRucIiz4IC0pzqApjTzSOJSyV_J6fYBwHuIAjLn4MZA36ZfVCmm3-KzqJcGAv9W9sDWBi7aI80CVKLFVJ2rh9l_9bMnANjm5fCsZ-pE_F4eW5BnqiU7xOoel31W2WF2brEWf9l5dibILU5E7inYKkQ9qPCS3Ei7uo9LTYQMWR4RQSglAsb5TsnijOPtGBvQgyuwOeI9vWBIcm7Y64NXuWKiv1iManbTepggpKhCSj9qPPizVV4v7Vv1IgHbvViRCE0uIvomLsL9qTxkBVK2s_h3welM9-9CE0WvoGkbYgsDc3nBQEx7Vj4hBiYJ0nD2_dWw.zslxDgOETvBaMOTQ.XAPYdrt5HXhvF53llXp40YkRHWBSrosYDc0UVLnqwJkAcNs3CQo8vWKSNqfc8l6CezvFPinul4LEp-eRrOqrpnhzAMf-W4O-s0jjF0dPsa3NII_qdi5bmCQhwxTVzo31SBiKn1aCBu8lQXSLUAz7z3UF6JyH1OkCXU3Ld8puF45QTRoTRPru8oNy8W8ZbchDj11IhEzrT9RPmWznCDQ3rs8M16R636-TuULXdSqJUGtXB3wteXu8lcgGpIMno1T6Bq2rI8Ncg_rCe6RgepAlEjlC0J0hpgMOk-EiXFDXN5N0NfEo6VSv9-M1v5THSJBThZIlcZrL-njz4G2NiDa30PSrQFqLgusYpZNpL1bHGsUbz_Xqvwlpjq-A5TcrqjxwWHkK383pY-tE064FKQuk93HnOee1gp4iRc9GLiqOK4vawSKStaSWe1oWxeFkDDuY85H3rFL1U8JzAC-vbPpozju82q7mONQto0q1fnCa80jtl5rDVsxzXLkEDbfwrvE-_13MKTLGc9io-PbEy6UgD9bAz5qvoOtNLWh0rcAbT5yhnZnruecB9l3yBsnbo60HQC_83mMzPWjGQaTm-ujO-hockrUSkezEO2JhNKrMWI5V-2aBNin_0UcSShMQnFy4P9baFKcyvrt2r3LNOvqfl_mK9qh57AOQw4vjhJRRaPVVacB8h5WCoiq8ut8wnHq3L2MvF9HId9T0Ug9FaPP76ofLziM.u19pyEql02PpVrFrki3RWA&state=af0ifjsldkj&session_state=c57cc0825bf8838fd2b6f14597ed34b5d9404493b216092e9daa766749cdac40.-1D9AEiTjPN-3hzlRFN97Q
- The authorization code from the above URL is in the code parameter (
code=4489572f-83c9-3589-b403-c4ecf8fb77f4).
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
The client_assertion
is a JSON Web Token (JWT). Generate the client_assertion
by signing the following JSON payload using the supported algorithms:
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' \
-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
}
Step 3 - Invoke Consumer Data Standards API
This section shows how to invoke the endpoints in the ConsumerDataStandards
v1.3.0
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.