I'm storing the refresh token for my session in a database and updating it everytime I update the access token. But the other day, my application was down for 60 hours and I was surprised to see that the refresh token still worked.
How long does it last?
Doesn't it defeat the whole purpose of having oauth2 in place if the refresh token can be stored this long?
+1There is no refresh_token reported life here , other than you "might" get a new one when you get a new access token. There is no standard per/se of how long a refresh token should last, we've seen forever as one option for other apps. It would stink if your app didn't run for 60 hours (which is very possible in a Zap's case), and then it could not run as you couldn't get a new token.
Another example: Microsoft's refresh token can last up to 90 days: https://learn.microsoft.com/en-us/azure/active-directory/develop/refresh-tokens.
+2It’s that balance between the user friction of having to authorise frequently and having longer lived refresh tokens. In Strava’s case you should only be exposing the refresh token at most once every 6 hours. Plus you should take care to protect it, when it’s at rest. The token still doesn’t allow you to impersonate and act like the user. All access with the tokens will be logged against your app. I’m sure Strava will be monitoring for unusual activity. Plus if compromise is suspected then you should revoke all tokens immediately. The users will be asked to reauthorise, but that shouldn’t be a big deal if it doesn’t happen too often.
Something I do with refresh tokens is encrypt them before putting in persisted storage. Then only decrypt them in memory for immediate use. That way, if your database gets compromised the tokens within it can’t be used. If someone gains privileged access to your servers then all bets may be off, depending on how well you protect your encryption key chain.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
