2

Is there a way to block all api calls while I wait for the refresh endpoint to return? I know axios has interceptors, but how would I delay all subsequent calls after the access token has expired? Otherwise the user would just get some error messages if it clicks something while the access token is still being refreshed. Seems more complicated than I first thought, am I missing something, is there some library that can already manage this?

I guess I could create a queue and cancel all calls while refresh is still ongoing, and then re-run those requests from the queue, but is there a more elegant/already implemented way?

Not to mention, I should also consider more than one tab could be open with the same session, so probably a BroadcastChannel is needed too. It gets pretty complex...

George
  • 181
  • 5
  • It's interesting I've never thought of it that way when I'm testing (*with fast internet speeds*) I get response and that works, however sending 2 rapid requests would made the 2nd request fail. You never mentioned refresh token rotation, I thought my implementation was immune to that, in my case which is custom built but is very similar to OAuth2 (from what I've read), my access token expires in 5 seconds, so that a hacker stealing this token will fail to do any HTTP request, but legit user has a cookie of refresh token which when they make 1 request it is filtered over RT controller /part1 – Aleksandar Apr 30 '23 at 15:35
  • And this received RT is checked against user's array of RTs: if it exists then it is both removed from the array (invalidated) and a new one is re-created alongside the AT (access token) and 200 response is sent. However your post made me google this 2 very fast requests issue, and of course I came up to an OAuth2 answer [here](https://serverfault.com/a/962723) at the end the user mentions you could keep the old refresh token for a short period of time but it ends there without implementation suggestion. I'm thinking maybe a setTimeout (*to remove used RT*) would suffice – Aleksandar Apr 30 '23 at 15:44
  • @Aleksandar yes, well in my case there can be alot of simultaneous requests happening (I load stuff from many different endpoints when entering certain pages for example), so this would be quite a problem. I did do something with setTimeout like you sugest that waits for a busy flag until the refresh is done, and it works pretty well, but just seems a bit hackish and maybe not 100% reliable. – George Apr 30 '23 at 19:01

1 Answers1

0

FWIW I think this is an example of an XY Problem. This answer doesn't say how to do what you asked to do, but rather suggests that you take a different approach to solving the underlying problem.

I would think this is something you'd need to handle on the server side. It doesn't seem appropriate to try to handle it on the client.

Any requests that get sent with a stale token would get routed through the token refresh workflow on the backend. The process of refreshing the token should be idempotent, so multiple successive or concurrent requests to refresh with the old token should return the same new token (or error, if the request is denied.)

If an earlier call had already started the process of refreshing the token, the resolution of these responses would be waiting on the new token to be available (or generated again using the same idempotent method, as mentioned above.)

On the other hand, if the user makes a request that doesn't require a session, that request handling would skip the token validation/refresh logic and just send the appropriate response.

Matt Morgan
  • 4,900
  • 4
  • 21
  • 30
  • FWIW not really an XY problem, because I stated clearly what I want to do, you just don't agree it should be handled on the frontend. On the backend there would be the same problem, you have to wait for another call to end before continuing the current call. Or, just create a queue (on backend or frontend) and replay those requests, which seems like the only viable solution right now. – George Apr 30 '23 at 13:30
  • I have to push back on that-- why do you need a queue? If every request with a stale token goes through the same check and refresh workflow, why does any call have to wait for any other call? It doesn't. – Matt Morgan Apr 30 '23 at 14:39
  • sorry if I misunderstood, but is it ok to make the refresh endpoint idempotent? Should you be able to reuse the same refresh-token multiple times with the same result? Also this means that you have to store the generated access token in a database, alongside the refresh-token that generated it... so I don't know, I would rather not store access tokens at all. Thanks for the answer btw – George Apr 30 '23 at 19:31