The RBHR APIs use the OAuth 2.0 protocol for authentication and authorization. The bank supports common OAuth 2.0 scenarios such as those for the web server, single page, and mobile applications.
To begin, obtain OAuth 2.0 client credentials from the Developer Portal. Then your client application requests an access token from the bank Authorization Server, extracts a token from the response, and sends the token to the banking API that you want to access.
The RBHR APIs support the following grant types at this moment:
All applications follow a basic pattern when accessing a banking API using OAuth 2.0. At a high level, you follow four steps:
1. Obtain OAuth 2.0 credentials from the Developer Portal
Register your application on the Developer Portal to obtain OAuth 2.0 credentials such as a client ID and client secret that are known to both the bank and your application. To register your application navigate to the Applications page from your dashboard and click to Add Application. Follow the new application wizard to provide application information and to select APIs your application will access. After saving information your application is registered and you can initiate OAuth 2.0 flow.
2. Obtain an access token from the bank Authorization Server
Before your application can access private data using a banking API, it must obtain an access token that grants access to that API. A single access token can grant varying degrees of access to multiple APIs. A variable parameter called scope controls the set of resources and operations that access token permits. During the access-token request, your application sends one value in the scope parameter.
Some requests require an authentication step where the user logs in with their bank account. After logging in, the user is asked whether they are willing to grant the permissions that your application is requesting. This process is called user consent.
If the user grants permission, the bank Authorization Server sends your application an access token (or an authorization code that your application can use to obtain an access token). If the user does not grant permission, the server returns an error.
3. Send the access token to an API
After an application obtains an access token, it sends the token to a bank API in an HTTP authorization header. It is not possible to send tokens as URI query-string parameters.
Access tokens are valid only for the set of operations and resources described in the scope of the token request. For example, if an access token is issued for the Account Information API, it does not grant access to the Payment Initiation API. You can, however, send that access token to the Account Information API multiple times for similar operations.
Available scopes are: Accounts API - AISP
Payments API - PISP
Cards API - PIISP
4. Refresh the access token, if necessary
Access tokens have limited lifetimes. Your application receives refresh token to access banking API beyond the lifetime of a single access token. A refresh token allows your application to obtain new access tokens.
Access Token issued through Access code flow
In the access code flow, the application has the user provide authorization through a form provided by the gateway server, which, if they grant authorization, provides an authorization code to the application. The application sends the authorization code to the provider API and is granted an access token in return.
A detailed description of the flows is available in the IBM Knowledge Centre.