Hey,
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 https://unityapi.webrootcloudav.com/Docs/en/APIDoc/Guide?Length=20
How to get a refresh token that is valid for 14 day?
Cheers
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
We developed our Jupiter Server to take the hard work out of the authenticating to APIs.
CommitCRM and Webroot are supported.
https://dentaur.com.au/jupiter-server/
For the WebRoot API, currently only
/service/api/console/gsm is supported.
https://dentaur.com.au/jupiter-server/developers/code-examples/webroot-get-all-sites/
But importantly you can see that C# and Powershell are much simpler now.
Kind regards
Andrew Dent
Dentaur Pty Ltd
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:
https://unityapi.webrootcloudav.com/Docs/en/APIDoc/RefreshTokenAuthentication
The response in the example at the end says expires in 299!
2) https://unityapi.webrootcloudav.com/Docs/en/APIDoc/GettingStarted#gettingStarted-refreshAccessToken
Response in refresh says expires in 199!
So no where it expires in 14 days!
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:
- username
- password
- base64 encrypted combination of the above
- client name
- client secret
- Access token
- 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
POC
Mirus IT
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
POC
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 https://tools.ietf.org/html/rfc6749. We do have another discussion that may help you here https://community.webroot.com/unity-api-forum-49/refresh-token-expires-in-5-mins-instead-of-14-days-340050
Refresh tokens carry the information necessary to get a new access token. In other words, whenever an access token is required to access a specific resource, a client may use a refresh token to get a new access token issued by the authentication server.
Refresh tokens carry the information necessary to get a new access token. In other words, whenever an access token is required to access a specific mcdvoice resource, a client may use a refresh token to get a new access token issued by the authentication server.
Any update here????
Hi, what are specifically after here Gonalc?
