Refinitiv Data Platform (RDP) is a cloud-based service, to provide unified access to Refinitiv content and services. RDP provides a single point of API-driven content and is backed by standard authentication and entitlements. It gives you access to a wide range of analytics and global market data in the Cloud to power your workflow-critical applications.
Applications can access RDP services through the RDP API gateway. First, an application needs to get an access token and refresh token from the authentication service by using the password grant. An access token is a short live token used in the header of a request message to get data from RDP services. A refresh token is a long live token used with the refresh grant type to renew an access token. For more information regarding the grant types, please refer to the OAuth grant types in the Refinitiv Data Platform article.
The authentication service is important and frequently used in the RDP API gateway. Invalid usages of this service can block refresh tokens or RDP accounts. This article introduces limitations and guidelines for the use of the RDP Authentication service.
There are three limitations that users must concern for the use of the RDP authentication service.
1. Token expiration
2. The authentication service request limits
3. Session limits
There are two types of tokens used by the RDP authentication service. The first one is an access token which is a short live token used in the header of a request message sent to RDP services. The latter is a refresh token is a long live token used to renew an access token.
Both tokens can expire. For example, with a standard machine account, an access token can expire in five minutes and a refresh token can expire in 15 minutes. The life of a refresh token can be extended to the next 15 minutes by using the refresh grant type. However, the total lifetime of a refresh token for a standard machine account will not exceed 18 hours.
The password grant type can be used to renew an access token and refresh token while the refresh grant type can be used to renew an access token and extend the life of a refresh token.
The following picture demonstrates how the tokens of the standard machine account expire and how to use the refresh grant type to renew an access token and extend the life of a refresh token.
If an application uses the refresh grant type with an expired or invalided refresh token, it will receive a response message with the HTTP 400 bad request status.
You can check the expiration time ("expires_in") of the access token from the HTTP response of the RDP authentication service. Now, the expiration time is 600 seconds (10 minutes).
"access_token": "<access token>",
The authentication service request limits
The following table shows the maximum and suggested number of requests that can be sent to the RDP authentication service per 5 minutes. If the maximum limit has been breached, the associated RDP accounts or refresh tokens will be blocked until the usage rate drops.
1000 per five minutes (500 in ap-southeast-1)
25 per five minutes
500 per five minutes (250 in ap-southeast-1)
50 per five minutes
- If applications send requests to the /token endpoint of the RDP authentication service with the same password grant type (a username and password) for more than 1000 requests per five minutes, that username will be blocked and applications will start receiving HTTP responses with the 403 (Forbidden) status codes.
- If applications send requests to the /token endpoint of the RDP authentication service with the same refresh grant type (a refresh token) for more than 500 requests per five minutes, that refresh token will be blocked and applications will start receiving HTTP responses with the 403 (Forbidden) status code.
Typically, each account has only one active session. If there is an active session for an RDP account, users can’t use the password grant type with that RDP account to retrieve a refresh and access token from the RDP authentication service. The RDP authentication service will return the 400 (Bad Request) status code with the following error.
"error_description": "Session quota is reached."
Users can invalidate the current active session by using one of the following methods.
1. Set the takeExclusiveSignOnControl parameter to true when using the password grant with the /token endpoint. This parameter will kill the current session if the number of allowed sessions has been reached. Then, a new refresh token and access token are created and sent to an application. After that, the previous refresh token is revoked and can’t be used to renew an access token.
2. Call the /revoke endpoint with the refresh token of the active session to invalidate the refresh token and access tokens associated with that refresh token
The followings are guidelines that users can follow for the use of the RDP authentication service.
1. When using the password grant, an application can set the takeExclusiveSignOnControl parameter to true to revoke the previous active session
2. An application should reuse an access token to connect to RDP until it almost expires. The current guidance is to refresh a minute before the expiration
3. An access token can be shared with other applications to retrieve data from RDP
4. An application needs to verify the HTTP status code on a response message when using the refresh grant type. If the HTTP status code is 400 (Bad Request), a refresh token used in the refresh grant type may be expired or invalidated. Therefore, an application needs to use the password grant type to renew an access token and refresh token.
5. Before an application exited, the /revoke endpoint can be called with the refresh token to release the session
The RDP authentication service allows users to get tokens from the password grant or refresh grant type. Then, users can use retrieved tokens to access data from RDP endpoints. To use this service, the number of requests for each RDP account must not exceed 1000 requests and 500 requests per five minutes for the password grant type and refresh grant type, respectively. Otherwise, the account will be blocked. To avoid these restrictions, users must reuse a retrieved access token instead of getting a new access token whenever requesting data.
1. Bal, G., 2019. OAuth grant types in Refinitiv Data Platform | Refinitiv Developers. [online] Developers.refinitiv.com. Available at: <https://developers.refinitiv.com/en/article-catalog/article/oauth-grant-types-in-refinitiv-data-platform> [Accessed 5 October 2021].
2. Developers.refinitiv.com. n.d. Refinitiv Data Platform APIs | Refinitiv Developers. [online] Available at: <https://developers.refinitiv.com/en/api-catalog/refinitiv-data-platform/refinitiv-data-platform-apis> [Accessed 5 October 2021].
3. Developers.refinitiv.com. 2019. Tutorials | Refinitiv Developers. [online] Available at: <https://developers.refinitiv.com/en/api-catalog/refinitiv-data-platform/refinitiv-data-platform-apis/tutorials#authorization-all-about-tokens> [Accessed 5 October 2021].