4

I currently work on an legacy app which somewhat loosely implements an OAuth2 flow. In short, when the user logs in with username/password, he receives an access/refresh token pair. The access token expires after 20 minutes whereas the refresh token has a lifetime of 180 days.

Now when the client gets a HTTP 401 Unauthorized due to an expired access token, it will use the refresh token to obtain a new access/refresh token pair. At the same time, we invalidate the old token pair in our backends database (we simply delete the entry).

This has some major issues since our clients are mobile apps and it sometimes can happen that a response from our server is not received by the client. So after our backend saves the new token pair, which the client doesn't receive due to for example network problems, the client no longer can get a new token pair because he still only knows about the old - now invalid - refresh token.

I was wondering if what we are doing is correct or whether we actually should never remove old refresh tokens from the DB as long as they are not expired. Or should we for example remember the last 1 or 2 refresh tokens for a user so even if a new one was created, if the client doesn't receive the response from our server, he can still try one or two times again with the old refresh token.

Or should we simply never send out new refresh tokens when obtaining a new access token and always use the same refresh token?

Is there any best practice to follow or is this all personal taste? I mean we can't be the first ones to run into this issue of mobile clients loosing responses due to network issues, right? :)

Jan Thielemann
  • 85
  • 2
  • 5
  • If your looking for opinions. You should not be using the username and password grant type. – Linda Lawton - DaImTo Mar 08 '22 at 09:43
  • What would be the reason? At some point the user has to log in using his credentials. I don't think we can get rid of this without killing all our old app clients which are already in the field. – Jan Thielemann Mar 08 '22 at 10:14
  • I am dealing with the same issue right now. In mobile apps when you are doing some work in background system can shut down your app at any time. I am thinking of doing an "acknowledgement" of refresh token when client receives it. Only upon acknowledgement it is made active and previous token invalidated. – LadislavBohm Mar 14 '22 at 18:02

2 Answers2

2

MEASURING MOBILE CONNECTIVITY OCCURRENCES

When there are mobile connectivity problems, I would expect the refresh token grant request to fail. For the request to succeed and the response to fail to reach the client (in such a small time window, eg 200ms) feels very much like an edge case.

I would aim to ensure good production logging around what is happening server side, so that you can be clearer about exact causes. It is easy to jump to the wrong conclusions otherwise.

ROTATING REFRESH TOKENS

The preferred behaviour from a security viewpoint is to revoke all tokens for the user when an old one is reused. However, the OIDC Specs indicate that this can cause usability problems in some setups, in which case other measures may be appropriate.

Exact behavior is provider specific - some Authorization Servers store and flag old refresh tokens and may allow them to be reused for a time period configured against the client application.

SECURITY v USABILITY

If dealing with high worth data I would use the more secure option, but if mobile consumption data is not especially sensitive, using non-rotating refresh tokens might be an appropriate measure.

RELIABLE APPS

In some cases OAuth clients will get a 401 when using a refresh token, and in addition to the case you mention, there are other possible causes:

  • Token signing or cookie encryption key renewal (in some setups)
  • Infrastructure changes such as a load balancing failover to alternate site (in some setups)

Apps should always be coded reliably to deal with this, eg:

  • When an API call fails with a 401, try to refresh the access token
  • When a token refresh fails, eg with a 401 or an invalid_grant value in the error response field, the user must re-authenticate

Note that re-authentication is sometimes a single sign on event. To see how this looks, you can run my Demo Single Page App and click Expire Refresh Token, then Reload Data.

SUMMARY

You cannot always guarantee no re-logins for 180 days in a distributed systems world. In terms of next steps, my preference would be to properly identify the cause and frequency of failures, and to see if reliability could be improved in the client application's code.

Gary Archer
  • 22,534
  • 2
  • 12
  • 24
  • I think the main issue is that we have homescreen widgets which regularly updat the data every 30 to 60 minutes. If you ride a lot of trains or busses, the chance of losing responses from our servers goes up a lot. Personally I wouldn't bother since the login credentials can be saved (encrypted with fingerprint/face) anyways but our users complain a lot and the widget stops working once the user gets logged out under the hood. Well its still working, it just doesn't load new data, which, for a widget that shows you your mobile data consumption, is particularly problematic. – Jan Thielemann Mar 10 '22 at 08:32
  • I updated my previous answer since I wasn't happy with it - I think it provides a better narrative now. – Gary Archer Mar 11 '22 at 09:10
0

I'm working on adding oauth 2 to an API we are building, so I haven't run into this particular issue yet but I am aware that it might become a problem for us. I've read about one workaround where instead of simply revoking/deleting a used refresh token, you would adjust its expiration to just a few minutes ahead of the current date. A small grace period basically. This gives the opportunity for a client to re-use it if they failed to receive a response with the updated tokens from a previous request.

One example of this is Fitbit, where they actually do something similar by giving revoked tokens a 2 minute grace period

https://community.fitbit.com/t5/Web-API-Development/Refresh-token-amp-network-timeout/td-p/1102761

I am not sure though if it still applies today because the post above was from 6 years ago.

georaldc
  • 1,880
  • 16
  • 24