How Authentication Works - Refresh Tokens

  • 2 November 2016
  • 9 replies

Userlevel 4
Badge +9
We have had a lot of questions around getting started with authentication, so I wanted to make sure there are some materials that help explain this. The Webroot Unity API uses OAUTH 2 to generate Access and Refresh tokens. Each token has a different TTL, and is designed for specific usage. Best practices dictate that an access token should only be generated using GSM credentials once during development, and then after that, refresh tokens are used to keep the product authorized. Here are some flow charts to help explain how these different tokens are generated and used:

Initially, you will use your GSM credentials to generate your first Access token. This is a combination of your GSM username/password, and your API credentials that have been generated in the GSM console under Account Settings > API Access. (For more information on generating these credentials, please visit

Once this access token is generated, the GSM username/password combination may be removed from future authentication requests, and replaced with the refresh token, as shown above. Note that when using a refresh token for your /auth/token request, you will need to add the body key : value pairs of
refresh_token : {refresh token generated from access token}
grant_type : refresh_token
scope : *
Here is an example of the complete HTTP request for refreshing an access token with a refresh token:
POST /auth/token HTTP/1.1
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic {access_token}
Cache-Control: no-cache

9 replies

Badge +2

Ive Implemented the exact same, however the refresh token returned has an expiry of 5 mins instead of 14 days as mentioned in the guide

How to get a refresh token that is valid for 14 day?

Userlevel 4
Badge +9
Hi @rhasan,

Most likely you are still using the authentication token request, which would account for the shorter TTL. Please review this documentation, and if you still continue to run into issues please reach out to our support team.

Best regards,
Joseph R.
Product Manager, Integrations
Badge +1
We developed our Jupiter Server to take the hard work out of the authenticating to APIs.
CommitCRM and Webroot are supported.

For the WebRoot API, currently only /service/api/console/gsm is supported.

But importantly you can see that C# and Powershell are much simpler now.

Kind regards

Andrew Dent
Dentaur Pty Ltd
Badge +2
Hi @rhasan,

Most likely you are still using the authentication token request, which would account for the shorter TTL. Please review this documentation, and if you still continue to run into issues please reach out to our support team.

Best regards,
Joseph R.
Product Manager, Integrations

Hey, thanks for the reply. I still didnt get through this. Further,
1) See the link:
The response in the example at the end says expires in 299!

Response in refresh says expires in 199!

So no where it expires in 14 days!
Badge +1
having a expiry of 14 days is a security risk in my view.
Much better to simply get another token using the API or refresh the token.

In our Jupiter Server code once the expiry occurs we automatically request a new access_token.
So someone writing a script or code against our Jupiter Server product doesn't need to worry about that the expiry of the token.
The Jupiter Server takes care of that automatically.

Importantly, the script or code you are writing doesn't even need to have any WebRoot credentials.
All that the script or code needs to do is to authenticate with the Jupiter Server.
The Webroot credentials for your GSM are fully encrypted in the config of the Jupiter Server.

I am going to feedback and say that the whole authentication method used is over complicated and unnecessary.


As part of my job, i pull data from systems far more sensitive than webroot and have much easier things to work with.


About another 2 days dev before i give up and feedback to my SMT the hours required to run and maintain using this API isnt work the value. 


Cant we just have a simpler authentication method that doesnt require this list of things to get data:


  1. username
  2. password
  3. base64 encrypted combination of the above
  4. client name
  5. client secret
  6. Access token
  7. refresh token

having 7 things is overkill. more annoyingly, WHY!?!? if the credentials were acceptable to start pulling the data, why do i need a refresh token to re-authenticate when you supply a contunationuri anyway!


Many Thanks

Mirus IT


Userlevel 3
Badge +9

Hi, thanks for your feedback. Unity has been built to use OAuth2 which is quite popular. I understand that token management can be a little difficult to get your head around at the start. You need to be build in to the main loop functions to refresh tokens and handle the life of the access token.  Note when you refresh the access token you don’t need the username and password.


Hi Chris,

I am aware of everything you have said, but i dont think you are getting the point.

As much as i like to see good security, there is such thing as over doing it. And in this case, access to the API information is too complex for no good reason.

A refresh token shouldnt be required if you have a continuation URI that ALREADY CONTAINS security credentials.

As a customer, it is very disappointing that Webroot have made accessing the information this way this hard. It shouldnt be “hard to get your head around at the start” when you consider the other API’s i query are just as secure but no where near as complex to code out. This cost me days of dev vs the hours of dev i put in to all my other API information suppliers. And you are not the most sensitive in terms of data.


It just shouldnt be this complex and you have capability to make it so it isnt this complex. Making customers dev out for days vs hours is not what i would call quality value being provided.


Many Thanks


Userlevel 3
Badge +9

Hi, yes there are different ways of implementing Authorisation and Authentication but we use OAuth2 and that’s  not likely to change soon. We use layers of security as Unity talks to multiple systems, OAuth2 roles allow for:

  • Resource Owner: the entity that can grant access to a protected resource. Typically this is the end-user.
  • Resource Server: the server hosting the protected resources. This is the API you want to access.
  • Client: the app requesting access to a protected resource on behalf of the Resource Owner.
  • Authorization Server: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0.


The Continuation is for paging through large amount of data whereas the access-token is for the actual API authorization. If you are having to do continuations, you can just set a different batchSize so they don’t have to use lots of Continuations.


You can find more a the OAuth 2.0 standard RFC 6749 We do have another discussion that may help you here