Authentication

Authentication is based on OpenID Connect, which is based on OAuth 2.0. 

The TPP submits an account request on behalf of a user, which contains information account permissions, transaction to and from date etc.

Once the TPP submits the account request, the user will have to authenticate with the bank using two-factor authentication, choosing the list of accounts they want to provide the permissions for, which will then provide the client application with a unique and time-bound access token. The client app can use this unique token to make calls to the bank on the behalf of the user, for accounts chosen by the user while providing consent.

Generally, these access tokens are specific to a single account request submitted by the TPP on behalf of a user.

For the accounts and payment APIs, users need to authenticate their accounts each time an API call is made because these API calls need to meet higher security requirements.

The end user authenticates the account and provides access to the app to carry out the transaction via a two-step verification on the bank site. The following steps are done to provide authentication:

  • Tpp submits an account request using client credentials access token.
  • The user is redirected to bank's server to provide consent for the account request TPP submitted.
  • The user is shown a log-in page, where the user logs-in with bank customer Id and password. 
  • The user is shown the consent page based on account request submitted by TPP earlier. The user verifies the perfissions TPP asked for, and the user selects the account(s). 
  • The bank then requests the user to verify this with an OTP, which is sent to the user’s registered mobile number
  • Once the user enters the OTP, an access token specific to that account is generated, which the app can then use to make calls on behalf of the user

 

Using APIs in your app

You will create an app and provide the required details to enable support for the OAuth 2.0 three-legged flows, such as the callback/redirect url.

In order for the app to make any API calls, it will have to present its client ID and secret. This is to ensure that only authenticated apps can make API calls. 

For accessing the accounts and payments APIs, the app will first make a call to the OAuth API, so that the app can get an access token to access account(s) on behalf of the user. The OAuth APIs support both the implicit grant flow wherein the access token is returned directly to the app once the user has authenticated. If the app wishes to keep the authentication more secure (which it should, unless it is a trusted app), then the app could also use the authorization code flow wherein a code is returned back to the app.  It should then exchange it for an access token.

The two flows are differentiated by specifying the response_code parameter as ‘code’ for the three-legged authorization code flow and as ‘token’ for the implicit grant.

The App can then use this access token to make the calls to the accounts/payments APIs. When the API is called, the customer and account information is retrieved from the access token and the account information is then presented to the user.

Account Access APIs

For accessing this API endpoint, the app will first make a call to the OAuth API to get a client_credential access token, then create an account request which will have the details of the access required.

The account request contains the information like account information permissions, the permission expiration time etc. 

Once the Account request is created, the app requests for an access token for the account request created. While providing the consent, the user selects the list of accounts it wants the app to get access to.

The app now gets an access token to access account(s) on behalf of the user. The OAuth APIs support both the implicit grant flow wherein the access token is returned directly to the app once the user has authenticated. If the app wishes to keep the authentication more secure (which it should unless it is a trusted app), then the app could also use the authorization code flow wherein a code is returned back to the app and it should then exchange it for an access token.

The two flows are differentiated by specifying the response_code parameter as ‘code’ for the three-legged authorization code flow and as ‘token’ for the implicit grant.

The App can then use this access token to make the calls to the accounts APIs. When the API is called, the customer information is retrieved from the access token and the account information is then presented to the user.

 

Payment APIs

For accessing these API endpoints, the app will first make a call to the OAuth API to get a client_credential access token, then create a payment request which will have the details of the payment initiation.

The payment request contains the information like creditor details, debitor details, the amount to be transfered, merchant details etc. 

Once the payment request is created, the app requests for an access token for the payment request made by the app. While providing the consent, the user selects the debit account through which the payment has to be made.

The app now gets an access token to submit one time single payment on behalf of the user. The OAuth APIs support both the implicit grant flow wherein the access token is returned directly to the app once the user has authenticated. If the app wishes to keep the authentication more secure (which it should unless it is a trusted app), then the app could also use the authorization code flow wherein a code is returned back to the app and it should then exchange it for an access token.

The two flows are differentiated by specifying the response_code parameter as ‘code’ for the three-legged authorization code flow and as ‘token’ for the implicit grant.

The App can then use this access token to submit the payment. When the API is called, the payment is submitted according to the payment request Id for which the access token was generated.

 

Open data APIs

Open data APIs are a category of APIs that provide non-customer specific information from a bank. These offer bank-specific information, such as ATM locations, products, URLs, and events. These APIs are not subjected to user-level authenication, but are protected to be used only by signed apps. A valid client credential is essential to make these API calls.