2

I'm quite new to the world of access and refresh tokens, so bear with me.

  1. Client uses its refresh token to get a new access token.
  2. The server invalidates the just used refresh token and contextually issues the new access token and a new refresh token.
  3. The connection drops or the client crashes, and the new refresh token is not received.
  4. The client tries again, but now the refresh token is invalid and the only option it has is to involve the user again.

Is there a standard/most used way to address this situation? Or is it deemed unnecessary?

One solution I can think of, is for the server to expect the client to acknowledge the new refresh token, before the server activates it. Does this make sense? Is it worth it?

Fabio A.
  • 125
  • 5

3 Answers3

5

Technically that's not a race condition. But rather a consensus problem.

Is there a standard/most used way to address this situation? Or is it deemed unnecessary?

Yes. Accept those rare cases and let them be. Its not a big deal.

One solution I can think of, is for the server to expect the client to acknowledge the new refresh token, before the server activates it. Does this make sense? Is it worth it?

What if ack doesn't arrive at the server? How can the client know this? The client has to know this, otherwise it won't know whether the token is actually active or not. Should the server ack the ack? But then how can the server know that ack of ack arrived at the client? Do you see the problem?

This is known as two generals problem. This problem is proved to be unsolvable. There are protocols (e.g. Paxos) that increase likelyhood of success, but in this particular case it is an overkill. You will have more problems maintaining it than dealing with those rare failures. So don't bother.

The consensus strategies should be applied when failures may have catastrophic consequences. Even if (or especially when) they are rare. Like bitcoin transactions. But that's not your situation.

freakish
  • 2,803
1

I always address the race condition of multiple requests all wanting to refresh at the same time. But I never bother with the Error handling of client not getting the new token.

I think this is mainly because its so rare. these days internet connectivity is generally reliable and there is a clear, "Log in again" path for the rare cases it comes up.

That said, with this type of auth you do have to handle a whole bunch of error cases around state and invalid tokens to make sure the user is redirected to login and has thier tokens cleared so you aren't having to tell people to clear their cache/press F5 harder rtc

Ewan
  • 83,178
1

What the user sees: First time they use the application they need to enter their username and password or the app doesn’t work. Then for some time it just works, then at some unpredictable time (for them) they need to enter the username and passcode again. Plus they can deliberately log out, and then log in again possibly with a different username.

So does this still work in your scenario, is the whole effect that they need to enter their credentials again? In that case there’s nothing to do. Is it possible that a transaction happens only half? (Say a customer ordered 100 different items, your server was told about 60 but not the other 40)? You make sure that the transaction is completed after the user acts, or completely cancelled and the user is told. This must be kept rare because it is highly inconvenient.

gnasher729
  • 49,096