Following the BerlinGroup standard and OAuth2 standard, the "scaOauth" property given after a consent creation (with the header tppExplicitAuthorizationPreferred = false) or after a POST /authorization
endpoint should contain an OAuth2 ".well-known" file. That being said, currently the "scaOauth" property contains the authorization URL.
In order to comply with these standards, this new functionality will be implemented in the production environment at a later date. Since this implementation constitutes a breaking change for TPPs, it will be available in a future version of our APIs.
However, the sandbox has been updated in order for you to begin implementing the required changes for your application.
Currently, on the production environment, the "scaOauth" property of a consent creation (with header tppExplicitAuthorizationPreferred = false) or a POST /authorization
endpoint is the following:
{
…
"_links": {
"scaOAuth": {
"href": "https://xs2a-api-web.bankvanbreda.be/public/berlingroup/authorize/31f68ab6-1ce6-4131-a324-3f37d2ca4b02"
},
…
}
}
You cannot access to the authorization process without adding some values to the scaOAuth URL - you have to complete it with the following parameters:
URI parameter | Description |
---|---|
scope | This parameter corresponds to the consentId of the consent creation or the paymentId of the payment initiation Examples: AIS:1587559935-bae68c2 PIS:1587561419-bp5b5f2 |
client_id | This parameter corresponds to your NCA id |
state | Dynamic value that you have to set in order to prevent XSRF attacks |
redirect_uri | This parameter corresponds to the URI where the OAuth2 server is redirecting the PSU after the authorization. NB : this redirect_uri has to be the same used for the consent creation or payment initiation |
code_challenge | This parameter corresponds to PKCE challenge according to cryptographic RFC 7636 which is used to prevent code injection attacks |
response_type | Type of the response. This value has to be set to “code” |
code_challenge_method | Optional parameter which corresponds to the code verifier transformation method ("S256" or "plain") |
Following these instructions your authorize URL should look like this and is now valid to process the authorization of the PSU:
This process to build the authorize URL is the same for a payment initiation or a payment cancellation with SCA.
NB : the "redirect_uri" parameter in the URL has to be the same as the "TPP-Redirect-URI" header of the consent creation
On the sandbox environment, the well-known configuration has been deployed in advance in order for you to begin implementing the required changes for your application. Here the "scaOauth" property of a consent creation (with header tppExplicitAuthorizationPreferred = false) or a POST /authorization
endpoint is the following:
{
…
"_links": {
"scaOAuth": {
"href": "https://xs2a-sandbox.bankvanbreda.be/berlingroup/.well-known/openid-configuration?authorizationId=11111111-1111-1111-1111-111111111111"
},
…
}
}
You have to call this URL and retrieve the “authorization_enpoint” property in the response:
{
"issuer": "http://xs2a-sandbox.bankvanbreda.be",
"authorization_endpoint": "http://xs2a-sandbox-web.bankvanbreda.be/berlingroup/authorize/11111111-1111-1111-1111-111111111111",
"token_endpoint": "http://xs2a-sandbox.bankvanbreda.be/berlingroup/v1/token",
"userinfo_endpoint": "http://xs2a-sandbox.bankvanbreda.be/berlingroup/v1/accounts",
"scopes_supported": [
"account",
"payment"
],
"response_types_supported": [
"code"
],
"grant_types_supported": [
"client_credentials",
"authorization_code",
"refresh_token"
],
"code_challenge_methods_supported": [
"S256"
],
"subject_types_supported": [
"public"
]
}
With this property, you will be able to build your authorize URL with the following parameters:
URI parameter | Description |
---|---|
scope | This parameter corresponds to the consentId of the consent creation or the paymentId of the payment initiation Examples: AIS:VALID_CONSENT_ID PIS:PAYMENT_ID_RCVD_SCT |
client_id | This parameter corresponds to your NCA id |
state | Dynamic value that you have to set in order to prevent XSRF attacks |
redirect_uri | This parameter corresponds to the URI where the OAuth2 server is redirecting the PSU after the authorization. NB : this redirect_uri has to be the same used for the consent creation or payment initiation |
code_challenge | This parameter corresponds to PKCE challenge according to cryptographic RFC 7636 which is used to prevent code injection attacks |
response_type | Type of the response. This value has to be set to “code” |
code_challenge_method | Optional parameter which corresponds to the code verifier transformation method ("S256" or "plain") |
Following these instructions your authorize URL should look like this and is now valid to process the authorization of the PSU:
This process to build the authorize URL is the same for a payment initiation or a payment cancellation with SCA.