Question

Refresh Token expires in 5 mins instead of 14 days

  • 28 August 2019
  • 8 replies
  • 84 views

Badge +2
Hi, I hope everyone is doing well.. Ive got an issue with the refresh token as it expires in 5 mins instead of 14 days.

As per this guide it should expire in 14 days:
https://unityapi.webrootcloudav.com/Docs/en/APIDoc/Guide#guide-authentication-accessAndRefreshTokens

Here is what im doing to test this:

1) get Access Token with:
header contains = `Authorization: basic *****`
body contains = username, password, grant_type='password', scope

2) get refresh token with:
header contains = `Authorization: basic *****`
body contains = refresh token (from step 1) grant_type='refresh_token', scope

and before you ask: im passing same scope!


So did I miss anything? or did anything wrong? Please help..
Thanks in advance for your help :)


8 replies

Badge +2
Furthermore,

If i pass
`Authorization: Basic {access_token}` instead of `Authorization: Basic {Base64 of clienid:password}`
I get
`client_id has not been sent`
Badge +2
Even look at the response given on this page:
https://unityapi.webrootcloudav.com/Docs/en/APIDoc/RefreshTokenAuthentication

It says expires in 299. So clearly something isnt working well or not documented correctly
Userlevel 2
Badge +6
Hello rhasan,

I think the manual may need updating to make things clearer. This question has been asked several times. We will look into it.

To answer your question. The Refresh Token has a “maximum” life of 14 days; a new Refresh Token is issued with every Access Token. So as soon as a new Access Token is granted, the previous Refresh Token is no longer valid.

In terms of authorisation, you do not need to issue the Username/Password combination within the Refresh Token body.

Hope this clears things up.
Badge +2
Hello rhasan,

I think the manual may need updating to make things clearer. This question has been asked several times. We will look into it.

To answer your question. The Refresh Token has a “maximum” life of 14 days; a new Refresh Token is issued with every Access Token. So as soon as a new Access Token is granted, the previous Refresh Token is no longer valid.

In terms of authorisation, you do not need to issue the Username/Password combination within the Refresh Token body.

Hope this clears things up.


Hey, thanks for the reply. However, how is it 14 days when the response says (and does) expire in 299?
Userlevel 2
Badge +6
If you do not obtain another Access Token for up to 14 days, you can use the same Refresh Token.
Userlevel 2
Badge +6
The 299 refers to the Access Token timeout of 5 mins.
Badge +2
oh i see... but to make any request whatsoever I still need access token. so it makes no difference from my end to even implement refresh token!

For example, I need to call this:

GET /service/api/console/gsm/{gsmKey}/sites/{siteId}/endpoints

I would need access token. which expires in 5mins. So even if i generate a ref token call I still get 5 mins access token. So why would I implement 2 calls when the outcome is the same?
Userlevel 2
Badge +6
That question may best looked up in the OAuth 2.0 standard RFC 6749 https://tools.ietf.org/html/rfc6749 but in short, using relatively short lived tokens (max 14 days) instead of username/password combo is more secure. In other words, you would only need to send the username/password combo just once in years of communication.

Reply