Skip to main content
To Customer Support To Customer Support
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 :)





Furthermore,



If i pass

`Authorization: Basic {access_token}` instead of `Authorization: Basic {Base64 of clienid:password}`

I get

`client_id has not been sent`
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
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.
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?
If you do not obtain another Access Token for up to 14 days, you can use the same Refresh Token.
The 299 refers to the Access Token timeout of 5 mins.
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?
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.

Good day!

I am still getting 5 minutes and I can’t refresh it.

I can’t seem to get the 14-day refresh token to work with me. If I follow the instructions on the guide for the refresh token, it complaints that I did not set the client_id or client_id is invalid.

using the refresh token guide but getting this error

Any thoughts how to get this working?

 

Thanks!

Ok, my apologies for this comment. I get it now. Thank you @ngoknel  :grinning:

Reply


Terms & Conditions