I'm having issues similar to what's described in this post. I read the list below. I added emphasis to #2.
Refresh tokens can be invalidated/expired in these cases
1. User revokes access to your application
2. The refresh token is used to obtain a new access token and new refresh token
3. The user goes through the Authorization process again and gets a new refresh token
(At any given time, there is only 1 valid refresh token.)
My question is related to #2. If my understanding of our issue is correct, this is what happens:
1) each time we get the user's data from the API, we use the refresh token to get a new short-lived access token. When we do this, the refresh token is also no longer valid, and we must store the new refresh token for future requests.
2) at some point, a database deadlock, a network problem, or something else will cause us to lose the refresh token. We now have nothing we can use to request the user's data -- the old refresh token is no good, and the new one is lost. We've added redundancy so that we don't lose the refresh tokens.
This is a rare occurrence, but we have tens of thousands of Fitbits connected, and something's bound to happen when you have that much throughput. With OAuth 1.0, the thing we used to access a user's data never changed, and we never had a single issue in 3 years.
My question: Is it possible to obtain a new access token without invalidating the refresh token?
The amount of redundancy my team has built into OAuth 2 token storage is getting ridiculous and is causing me to question what we've done and make sure our approach is correct.
