As asked in the subject, can you advise when there is a need to re-send the request for a new Refresh Token before the previous one is expired? The post states that Access Token is expired in 5 mins but doesn't mention that of Refresh Token.
As asked in the subject, can you advise when there is a need to re-send the request for a new Refresh Token before the previous one is expired? The post states that Access Token is expired in 5 mins but doesn't mention that of Refresh Token.
Hello @updated already
Thank you for your participation in the forum. Is the reply below satisfactory in resolving your query?
If so please can you click the 'Accept' text next to the appropriate reply? This will guide all community members who have a similar question.
Thanks,
AHS
Please be informed that a reply has been verified as correct in answering the question, and has been marked as such.
Thanks,
AHS
A few points of clarification.
There are two types of credential a user may use to access RDP APIs + data
A username is designed for display type usage only (e.g. for testing with the RDP API Playground) and will therefore expire within 18hrs and only allow a single connection at a time. It must not be used for programmatic access to RDP data.
A MachineID is for programmatic access to RDP data and a correctly configured one should never expire under normal circumstances and it should also allow 5 concurrent connections.
If a MachineID is expiring on a regular basis then this means the MachineID was incorrectly configured and needs to be recreated.
Having said all the above, a MachineID may occasionally expire due to various exceptional circumstances. Therefore, a robust application should be coded defensively to handle this possibility. Both the above techniques that myself and my colleague Gurpreet mention should be included in a robust application i.e. using a password grant login to obtain a new Refresh token when:
I hope this clarifies the position on Refresh Token expiry
Whilst I cannot confirm how long a Refresh Token lasts, the various RDP Websocket API examples (Python, C# and Java) demonstrate that when you are trying to get a new Access Token; if you get error 400 or 401 - but you already have an existing RefreshToken - then you should log in again using username and password etc to get new Refresh Token
e.g. Python snippet:
def get_sts_token(current_refresh_token, url=None): ....
elif r.status_code == 400 or r.status_code == 401: # Retry with username and password print('EDP-GW authentication HTTP code:', r.status_code, r.reason) if current_refresh_token: # Refresh token may have expired. Try using our password. print('Retry with username and password') return get_sts_token(None)
....
where r is the response from the requests.post call
Any developer writing an application that uses OAuth2 with Refresh and Access tokens should implement the above functionality - rather than hardcoding any particular value for getting a new Refresh Token
The refresh tokens typically last 18 hours.
When your application detects that the expires_in key in the Refresh Grant response is not equal to the original expires_in key, this implies that your refresh token has expired and the application should use Password Grant to continue.
Thanks, @Gurpreet. May I know what's 'Refresh Grant Response' you referred to? By calling Token service endpoint https://api.refinitiv.com/auth/oauth2/v1/token, the value of key 'expires_in' in the response is for Access_Token only, right? I didn't see Refresh_Token value changes through a series of calls during an hour.
See the expire_time usage in this sample code - https://github.com/Refinitiv/websocket-api/blob/master/Applications/Examples/RDP/python/market_price_edpgw_service_discovery.py