Understanding OAuth Refresh Token

Question on OAuth Refresh Token:
I understand how it all works programmatically and have it working. My question is: Will there not be a race condition when performing a refresh to get new access token that will ultimately invalidate the refresh token and force the user to have to manually re-connect via UI?

Context: See here - “Note that using a refresh token more than once will result in revocation of the token. The user will need to re-authorize your integration if this occurs.”

So if 2 users that utilize the same OAuth Key, pings your server simultaneously and your server determines that it needs to refresh the access token (which expire every 60 minutes so will happen often), then the server will simultaneously perform a refresh using the same refresh token, the 2nd one that hits Airtable API will trigger the revocation of the token and require the re-authorization per the note above. Is that correct?

Other OAuth providers I have used (although not all) have been smarter about this and allow for multiple refresh tokens to be active simultaneously (up to a limit - maybe 3). That allows for the token to be refreshed simultaneously like in my example.

I have some alternative ideas on how to approach this but first want to make sure I’m understanding how this works. Is that how others interpret it?

You know more about OAuth than me, but the use case you describe doesn’t fit my understanding.

My understanding is that each OAuth authorization instance comes with both an access token and a refresh token. Different users (or the same user at different instances) would have different access tokens / refresh token combinations. When you use the refresh token, it would invalidate its corresponding access token, but not the access token from a different OAuth instance. Each OAuth authorization should be used / managed by only one service so that the same refresh token would not be used by two different services.

This is just me reading documentation. I haven’t actually tried it.

On the other hand, I agree with you that instant revocation and only one refresh token is problematic. What if there is a network error in the process of retrieving the new access token after the previous one is revoked? Then you are stuck with having to go back to getting the user to manually reconnect.

yes, that is correct. but not quite my scenario.

its common for multiple incoming request to utilize the same oauth token. For example, with On2air Forms. If 2 different people submit the same form at the same time, there will be a race condition to refresh the same oauth token from those 2 submissions.

Do you have a queue for processing those incoming requests? If you have a queue, only one request would be using the access token/refresh token at a time. If you don’t have a queue, how do you ensure that you aren’t hitting the API rate limit?

understood, that is a potential workaround. but the penalty for hitting the api rate limit is much lower than the penalty of invalidating your oauth token.

And to clarify, my concern isn’t about how to work around the issue. Its more of whether I need to worry about it in the first place based on how they implemented their refresh flow and if I’m understanding it correctly.

In that case, my understanding matches yours, and it would be a problem. Have you talked to Emma Yeap about it?

It seems like Okta is also using similar approach to invalidate all access token, if refresh token is reused. This seems to be deliberate security feature:

However in their case they allow to enable 0-60 sec grace period, to cater for eg. poor network conditions.

Looking at Airtable wording - I would read it the same way as @dan - race conditions, 2 requests could disable Oauth, if there is no grace period around. I am planning to implement the Airtable Oauth down the line, so interested to learn more if you get any more info on this.