Here we list the most common errors encountered in Rabobank OAuth 2.0 flow on the client side. These use cases list reasons for errors and how to troubleshoot them.

Obtaining Authorization

During the Authorization call to get the consent of the user, the TPP may encounter the following:

Invalid client id supplied

You receive an HTTP response of 401 Unauthorized with the message invalid client id or secret while invoking an Authorization flow.

This could be caused by one of the following:

1. Invalid client id is supplied in the request.
2. Your TPP application is not subscribed to an API using OAuth 2.0.

To solve this issue, your application should be subscribed to an API using OAuth 2.0 and provide a valid client ID.

Redirect URI mismatch

When registering an application, you should provide a redirect URI on the Rabobank developer portal.

If you have more than one redirect URLs listed in the developer portal, make sure to provide one of the redirect URI (as provided during registration) in the redirect_uri query parameter during an Authorization call. If the redirect URI from your request does not match with the one registered on the Rabobank developer portal, you get the following error:

Requesting access token

To access the requested resources, you should exchange the received authorization code for an access token. During the retrieval of the access token, you may encounter the following:

Invalid authorization code (grant type code flow)

The authorization code should be sent to the token endpoint to get the access token. Sending an invalid authorization code (expired, invalid, or already used) results in the below error:

Http status: 400 (Bad request)
{"error": "invalid_grant"}

To avoid this error, you should pass the correct authorization code before it expires (expiry: 5 minutes). Make sure to not call the token endpoint multiple times using the same authorization code.

Adding a slight delay of 1000ms before calling this endpoint ensures that the authorization code is in sync across our servers.

Invalid refresh token

Sending invalid Refresh token to get access token results in the below error:

Http status: 401 (Unauthorized)
{"error": "invalid_grant"}

The Refresh token can only be used once. To avoid this error, you should pass a valid Refresh token and not use the same token multiple times.

Invalid authorization header

While making a call to the token endpoint, an Authorization header should be provided consisting of a client id and client secret. If an invalid combination is passed, it results in the below error:

Http status: 401 (Unauthorized)
{"error": "invalid_client"}

To avoid this error, you should use the correct client id and client secret and make sure that the Authorization header is prepared as specified in the OAuth documentation.

Grant type missing

While making a call to the token endpoint, the grant_type query parameter should be provided. The value of this query parameter is based on the type of authorization you are passing to the endpoint.

For example, if you are swapping an authorization code for an access token the value of the parameter should be the authorization_code.

An example of the error message returned is as below:

Http status: 400 (Bad request)
{"error": "invalid_request"}

To avoid this error, make sure to provide all the required parameters, including grant_type.

Requesting resources with an access token

Access token invalid

The Access token issued by the authorization server if of limited validity. The expiry time of the access token is available in the response of the token request.

You should always use the expiry time from the response for each access token instead of hardcoding it to avoid customer impact in case the value changes.

Passing an expired or invalid Access token while accessing the resource results in the following error:

{
  "httpCode": "401",
  "httpMessage": "Unauthorized",
  "moreInformation": "This server could not verify that you are authorized to access the URL"
}

To avoid this error, you should always check the expiry time associated with the access token. If the token is expired, use a Refresh token to receive a new Access token.

If you are unable to get a new access token using the refresh token, it could be because the user consent is either expired or revoked. You can validate the consent using the Consent Details Service API.

If this is the case, you should renew the consent before proceeding.

How to check if the user consent is expired (or) revoked?

Using the information you received during the authorization flow, you can retrieve the consent by a specific Id as explained in the API Consent Details Service documentation.

If the consent status is one of the following, the consent is not valid and cannot be used to access the resources:

• expired
• revokedByPsu
• terminatedByTpp
• received
• rejected

Using an invalid consent results in the following error:

{
  "httpCode": "403",
  "httpMessage": "Forbidden",
  "moreInformation": "CONSENT_INVALID"
}

To access the resource gain, you should follow the authorization flow again and ask the user permission(s) to the required resources.

Deactivated or Expired consent

The consent of the user may be expired or revoked by the user, while your access/refresh tokens are still active, this results in a 403 Forbidden CONSENT_INVALID error message.

Not having the required permission to access an API

{
  "httpCode": "403",
  "httpMessage": "Forbidden",
  "moreInformation": "FORBIDDEN"
}

A 403 Forbidden FORBIDDEN error can be triggered if the Access token included in the request does not contain the correct scope for the API being used.

Example: You have an access token for the scope paymentRequest, but you are trying to access the Account information API, this API requires a different scope: 'ais.balances.read'.

To avoid this error, follow the authorization flow with the correct scope required for your API.