- single page application using access and refresh tokens to interact with an API
- refresh is one time use, as recommended by the OAuth security best practices[1]
- SPA is open in more than one tab
- two tabs try to refresh the token at the same time, second one fails because refresh token is used up
0: https://bsky.app/profile/ambarvm.bsky.social/post/3lakznzipt...
1: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur...
Two tabs try to refresh the token at the same time, user opened tab 2, tab 2 can't refresh because things locked in tab 1 - user thinks app is broken? Isn't that the way it would happen. I guess you can detect it is locked in another tab though so you could give the user a warning about this?
I guess I am missing something about the scenario..
Let's play it out.
- User authenticates, gets an access token A1 and a refresh token R1. R1 is one time use only.
- A1 and R1 are stored as cookies (secure and httponly to prevent XSS).
- A1 is used to access multiple APIs, but is only good for 5 minutes.
- The SPA opens up a new tab for whatever reason, so the browser is making requests to the APIs from both tabs (T1 and T2)
- 5 minutes passes, and T1 tries to call an API. The API call fails because A1 is not valid. T1 then makes a request to the OAuth server with R1, which returns a new access token (A2), a new refresh token (R2) and invalidates R1.
- 0.1 seconds later, T2 tries to call an API with A1, and also discovers it needs to get a new access token. It tries to use R1, but R1 is invalid because it has already been used
With this locking API, T1 could lock access to R1 when it was about to use it. T2 would then see the lock request fail, and not try to use R1. After R2 has been stored, T2 could use R2 (or T2 could use A2).
The URL is the command line and all that.
But like you, I sometimes feel like an old person yelling at the cloud.