Access/ Refresh token renewal process

[hazeena farook]

Hello, i have a the question: We use a webex integration in one of our applications, to authenticate users. When we do that we store that token (and the refresh token) in the database. Every 10 to 14 days before the token expires we use the refresh token to refresh it and create a new one. Unfortunately after some time the refresh requests fails (message: Token may be malformed revoked or expired). After a bit of research we found out, that after every refresh we get that same refresh token back from webex (so we basically refresh the token but keep the same refresh token). Because of the the refresh flow will fail after 90 days when the refresh token expires. Can we prevent this and refresh the token for a longer time period?

[hazeena farook]

You can create an Integration and use that to generate your access and refresh tokens. Integrations require that you authorize with them through a browser as you have to grant permission but once you've gone through the OAuth flow and have your access and refresh tokens then you can use the refresh token to programmatically generate new access tokens. The access token is valid for 14 days and the refresh token is valid for 90 days. However, when you use the refresh token to generate a new access token the expiry timer on the refresh token will reset back to 90 days. If you're using the refresh token once every 14 days to generate a new access token then the refresh token will never expire and you'll never have to manually go through the OAuth flow again. 

Reference artciles:
https://developer.webex.com/docs/integrations

https://developer.webex.com/blog/real-world-walkthrough-of-building-an-oauth-webex-integration

[lionelseydoux]

Hello. I'm struggling with the same problem. When refreshing the access token using the refresh token, I get a new access token valid for 14 days, but the returned refresh_token_expires_in parameter is still going lower... I'm expecting it to expire after 90 days, forcing me to do a user interaction to regenerate a new refresh token.

In your post above, you mention that when using an Integration, the refresh token is reset back to 90 days when generating a new access token. But that not the case: I've try with both Integration and Service App, and the refresh token is never reset back to 90 days.

What is done wrong ?

Let's refresh it:

https://webexapis.com/v1/access_token
grant_type=refresh_token&client_id=AAA********&client_secret=BBB******&refresh_token=CCC***********

{

    "access_token": "ZGI*********",

    "expires_in": 1209599,

    "refresh_token": "CCC***********",

    "refresh_token_expires_in": 7774228,

    "token_type": "Bearer",

    "scope": "spark:kms spark-admin:devices_read"

}

Let's refresh it one more time:

https://webexapis.com/v1/access_token
grant_type=refresh_token&client_id=AAA********&client_secret=BBB******&refresh_token=CCC***********

{

    "access_token": "NHI*********",

    "expires_in": 1209599,

    "refresh_token": "CCC***********",

    "refresh_token_expires_in": 7773125,

    "token_type": "Bearer",

    "scope": "spark:kms spark-admin:devices_read"

}

the access token starts again at 14 days (1209599), but the refresh_token not (from 7774228 to 7773125).

Is it because I'm trying the refresh too often ? will it be reset to 90 days if I call again the refresh in 2-3 weeks ? I don't see anything in the documentation about it.

Best regards,

[sandiban]

Hi @lionelseydoux, 
Thanks for raising the query!
So, when we are looking at the values of the Refresh Token lifetime in the API Response, I'm sure you understand the unit of this parameter is in Seconds.

So, if you convert these values is Days, then you won't really find any major difference there actually.
7774228 Seconds is equivalent to 89.97 days and 7773125 Seconds equivalent to 89.96 days. So, it's not like when you're running the same Access Token regeneration process using the existing Refresh Token, Refresh token lifetime is getting decreased by 2 days or, more than that.
Yes, I agree there is a decrease in the number in the second iteration as you showed, but this figure is something managed by the System and System tries to invoke the lifetime of the Refresh Token to the nearest decimal value of 90 days in Unit of Seconds.
System doesn't remember last time during the Access Token generation process, what it invoked as the lifetime of this Refresh Token. It calculated some nearest possible value of 90 days in Seconds and invoked it.
In the second iteration, System again does a fresh calculation to convert the 90 days in Seconds and invoke it as Refresh Token lifetime.

At times, it might seem like Refresh Token lifetime is getting decreased, but may be after too many iterations you might find the refresh Token lifetime is increasing as well since System is calculating this value each time independently. 
I believe this difference is negligible since every time system is coming to a value of 89.9X Days if we round off this Second value conversion to Days !
And, as you mentioned here since you're doing a back-to-back operations, that's why possibly Refresh Token value is getting decreased, No - I don't think that's the case here anyway. You can perform n-no of such operations, as many times you want. There is no harm in performing such operation this way.

Hope this helps here! Please let us know for any further queries.

Regards!
Sandip

[lionelseydoux]

Hi Sandiban,

Thank you for you reply. Yes I do understand that the lifetime in in seconds :-). At the time time of the generation of the access token and refresh token, the refresh token is set at 7776000 or close (90days). I was testing for some time, and in the example above, when I received 7774228, it just because I did a refresh ~30min later. When I received 7773125, I just refreshed it ~2min later again. Therefore no, it doesn't calculate a value close to 90 days... The system obviously knows when the token was created and just return the diff with the time of the refresh (and of course calculates it for a time-to-leave of 90 days). These tests were performed on Friday the 15th of September. This morning, the 18th of September at 7:30 I've done a refresh again. I get 7530785 -> yes, the lifespan continues to decrease in seconds (2.8 days later than the last test, which is absolutely correct). And now at 8:00, I refresh again and get 7528940 -> the refresh token decreased again by 1845 seconds, which is 30min.
I therefore expect the refresh token to be expired in 87,14 days... and then ? How can I automatically regenerate a new access token without any manual intervention ? For me it' still not clear Ho I could have tokens for automation for longer than 90days. Again, I've tested both Integration and Service App: same behavior.

Or maybe, after a long period (weeks, months), the refresh token goes again back to 90days, as long I we do refresh it. Unfortunately it is not documented. My only chance now it to wait and see if the refresh token gets expired in 87 days:-( , which is not really nice.

Best regards,
Lionel

[lionelseydoux]

Hi again Sandiban,

After a few tries this morning, the refresh token started again at 7775999 (90 days): for both integrations and serviceapp. Maybe I have an explanation for the problem. Here is what I did last Friday:
- Generate new access refresh token
- Refresh token a few time, but never used the access token to perform requests
- the refresh token counter always decreased.. until this morning

Today, I after the refresh, I started to use the new access token. After a new refresh, the refresh token started again at 90days.

Unfortunately I cannot reproduce it so easily. But long story short, it the refresh token TTL related to the fact that use (or not) the generated access token ?

Best regards,

Lionel

[sandiban · Accepted solution]

Hi @lionelseydoux,
Thanks for your patience so far!
So, I discussed this item once again with our backend team as well as the Team who manily manages these Tokens generations & expiry limit.
As per their comment, this behaviour is expected! Because the Refresh Token lifetime is not immediately updated to the correct seconds value of 90 days.
If we keep generating back-to-back Access Tokens using a Refresh Token, then definitely Refresh Token value should have been updated to 90 days but that takes some time.
And this waiting time ranges between exactly 1 - 5 days. At worst case after 5 days, automatically the Refresh Token lifetime is reset to 90 days and this whole process is taken care from backend.
At the time of those back-to-back generation of Access Token, they just put a randomly calculated Seconds value as Refresh Token lifetime which is closely rounded off to 90 days, but as I said after 1-5 days - this random value is automatically corrected and reset to 90 days.
So, initially it might looks like this is something unexpected, but that part is taken care of.
Hope this helps! Please let us know for any further assistance.

Regards!
Sandip

[lionelseydoux]

Hi Sandip,

Yes it works as you explained. I had a look every day on the expire value of the refresh token. Suddenly, after 3 days, it has been reset to 90days. It would be nice if Cisco could document this here https://developer.webex.com/docs/authentication. I must admit the handling of the API is very well documented... just one more line about this in the refresh section would make everything crystal clear

Thanks and best regards,

Lionel

[sandiban]

Thanks for checking @lionelseydoux and sharing your confirmation on this item!
Yes sure, let me discuss this internally within our team if this same information can be updated in the Developer Portal Doc. too. I'll be on top of this and will try to take care of it as soon as possible.
Thanks for your continuous follow up!

Regards!
Sandip

[dstaudt]

Not sure where/if it's documented, but my understanding is that refresh token expiry is only updated after some minimum amount of time has passed - i.e. it will not be changed/updated if refreshed immediately, but only after a particular period of time (days?) has passed.  I believe this behaviour helps reduce churn on the backend authentication system for perhaps too-eager token refreshing by apps.