4 ms·

I guess I don't actually get the point, because if I am locking a resource in one tab so that other tabs can't use that resource... how is that not going to lea

I guess I don't actually get the point, because if I am locking a resource in one tab so that other tabs can't use that resource... how is that not going to lead to behavior that a user would think was broken. 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..

mooreds 2y ago
It's not locking the UI refresh, it is only locking the access token refresh. 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).
- bryanrasmussen 2y ago
  thanks, this was the part that clarified for me "After R2 has been stored, T2 could use R2 (or T2 could use A2)."
  - mooreds 2y ago
    Awesome, glad it helped!

mooreds 2y ago

It's not locking the UI refresh, it is only locking the access token refresh. 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).

bryanrasmussen 2y ago
thanks, this was the part that clarified for me "After R2 has been stored, T2 could use R2 (or T2 could use A2)."
- mooreds 2y ago
  Awesome, glad it helped!