The RBRO APIs use the OAuth 2.0 protocol for authentication and authorization. The bank supports common OAuth 2.0 scenarios such as those for 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 RBRO APIs supports 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:
- 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 Applications page from your dashboard and click to Add Application. Follow the new application wizard to provide application information, provide OAuth redirect URI and 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 an access token permits. During the access-token request, your application sends one or more values in the scope parameter.
If the user grants the permission, the bank Authorization Server sends your application an authorization code. The application sends the authorization code to the provider API and is granted an access token in return. If the user does not grant the 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.
4. Refresh the access token, if necessary.
Access tokens have limited lifetimes. If your application needs access to a banking API beyond the lifetime of a single access token, it can obtain a refresh 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.
Detailed description of the flows is available in the IBM Knowledge Centre: IBM Knowledge Center