SVB has implemented FAPI standards to authenticate and authorize requests to our APIs.
Obtaining Access Token with private_key_jwt
TPP's must request for an access token by using the private_key_jwt method and you must sign the JWT. Please provide a valid API scopes (accounts, payments, or fundsconfirmations) which was granted during Dynamic Client Registration. On completion of validation the access token is provided in the response.
POST /token
The POST request must be made with the below mandatory attributes in the header:
| Name | Description | Type |
|---|---|---|
|
Content-Type |
Value should be application/x-www-form-urlencoded |
String |
|
grant_type |
client_credentials authorization_code refresh_token |
String |
|
scope |
must be either accounts, payments, or fundsconfirmations | String |
| client_assertion_type |
urn:ietf:params:oauth:client-assertion-type:jwt-bearer |
String |
| client_assertion | the signed jwt | String |
The client_assertion JWT claims:
- alg:PS256
- iss and sub must contain client_id that was provided during Dynamic Client Registration
- aud: as provided in the well know endpoint
- All other mandatory claims information as provided in the standard must be provided
Note:
- Scope is required for token access when grant_type = client_credentials, or refresh_token (with openid). For exchanging authorization code for access token scope is not required.
- For access token in exchange with authorization code, and refresh token we will respond with an access token, refresh token and id_token. Refresh token is provided only for AISP, and CBPII requests.
Authorisation Request
TPP's must create an authorization request by providing a signed request with a valid consent id for the PSU to consent to the request. On authorization by the PSU an authorization code and id_token is generated and the PSU is redirected back to the TPP.
GET /authorize
This API will enable the authorization of a consent. Invoking this request with valid query parameters will trigger the consent flow which involves the online banking login flow.
| Name | Description | Type |
|---|---|---|
|
redirect_uri |
The registered URI of the app client to be invoked after user consent authorization |
String |
|
scope |
The Open ID scope for which the token will be granted consent. Possible values : Open ID; accounts, payments, fundsconfirmations |
String |
|
response_type |
this should be 'code id_token' |
String |
|
client_id |
The API consumer key provided by SVB to the TPP |
String |
|
ConsentId |
The id of the consent that you are wishing to authorise |
String |
| request | the signed jwt | String |
The request JWT claims:
- alg: PS256
- iss: must contain client_id that was provided during Dynamic Client Registration
- aud: as provided in the well know endpoint
- openbanking_intent_id and sub: must provide the consent id
- max_age: Currently we do not support max age feature and hence if max_age is provided then the the value must be '300' seconds
- All other mandatory claims information as provided in the standard must be provided
Sandbox Testing
For consent authorization in Sandbox, we do not use SCA within this environment, we therefore provide a 'headless authorization' method for Sandbox.
- In order to authorize a consent in the SVB sandbox you need to register an app in the SVB developer portal
- The redirect_uri provided in the Get /authorize request must be the same as the redirect_uri registered for the app in the developer portal
Headless authorization will authorize a consent automatically when requested using the standard HTTP GET /authorize request - an example can be found below: