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/.
Authorize API for Berlin
The banks who wish to override the default consent page and integrate their own page can perform this by using the Authorise API. This is a REST API and it provides the following functionalities:
- Display information on the consent page.
- Capture the data on the consent page and persist them
The above functionalities are fulfilled by the following API resources:
GET /consent/data/{session-data-key}
The retrieval endpoint invokes this an API to retrieve consent data from the solution and account data from the bank back end. Then the consent page invokes the GET /consent/data/{session-data-key} endpoint.
If you have the following configured in the <WSO2_OB_IAM_HOME>/repository/conf/deployment.toml
file:
[oauth] prompt_consent=false
- If
prompt_consent
is set tofalse
, the value for the session-data-key path parameter should the session-data-key in the current communication session. - If
prompt_consent
is set totrue
or not configured in the file, the value for the session-data-key path parameter should be the sessionDataKeyConsent attribute in the current session.
Manual user authentication adds the above attributes to the session. For manual user authentication, you need to invoke the /commonauth
endpoint.
PATCH /authorize/{consent-id}
You can capture the information on the consent page and persist them. The consent page needs to invoke the PATCH /authorize/{consent-id}
endpoint to capture and persist information. By default, account and consent information is persisted.
Authorising accounts consents
Given below are sample requests and responses when you authorise an account consent.
- It is mandatory to include the userId, authorisationId, and permission fields in the request body.
- For the authorisationId field in the request payload, you can use authorisationId that you have retrieved from the above GET /consent/data/{session-data-key} request.
- For the permission field, the available permission levels are
AllPsd2
,AvailableAccounts
,AvailableAccountsWithBalances
, andDefault
.- If the value of the permission field is set to Default, it is mandatory to set the
allAccountsList
,transactionsList
,balancesList
values in the request body. If these values are not available, you can pass an empty array like this []. - If the permissions value is set to either
availableAccountsWithBalance
,availableAccounts
orallPsd2
, it is mandatory to have theallAccountsList
array in the request.
- If the value of the permission field is set to Default, it is mandatory to set the
- When the permission field is set to
Default
:
- When the permission field is set to
availableAccountsWithBalance:
The
availableAccounts
andallPsd2
permissions also follow the same format asavailableAccountsWithBalance.
Authorising payment consents
Given below are sample requests and responses when you authorise a payment consent.
- It is mandatory to include the userId and authorisationId fields in the request body.
- For the authorisationId field in the request payload, you can use authorisationId that you have retrieved from the above GET /consent/data/{session-data-key} request.
Authorising funds-confirmation consents
Given below are sample requests and responses when you authorise a funds-confirmation consent.
- It is mandatory to include the userId and authorisationId fields in the request body.
- For the authorisationId field in the request payload, you can use authorisationId that you have retrieved from the above GET /consent/data/{session-data-key} request.
POST /oauth2/authorize
This resource is to generate an URL with an authorisation code. Given below is a sample request and response for all types of consents (accounts, payments, funds-confirmation consents).