-
Notifications
You must be signed in to change notification settings - Fork 818
Description
So one problem any application implementing OAuth2 can have is issuing a request to refresh the access and refresh token but not actually receiving them and then forcing the user to re-authenticate. The most common case of this for us is native mobile applications that do a lot of background work and run into issues of network connectivity and or background process time limits (ie iOS gives you 30 seconds) and are unable to complete the full request/response life cycle before one of those cuts it short. The application then doesn't have the current refresh token from the backend and the only recourse is to have the user re-authenticate, which isn't ideal.
Currently the library offers the ability to completely disable rotation, so combined with either a much longer lifetime, or just disabling it altogether, you can work around the issue, but that too isn't ideal from a security standpoint.
I've looked into the issue some and ran into a company that was open in how they dealt with it and you can read about that here: https://community.fitbit.com/t5/Web-API-Development/Refresh-token-amp-network-timeout/td-p/1102761 -- I don't think their solution was necessarily the most ideal, but it's definitely better than nothing.
My proposal would be to have the following:
- Instead of the refresh token being revoked immediately, associate it with the new access token directly (ie
previous_refresh_token) - When access token is "used" for the first time, check to see if a
previous_refresh_tokenis associated with it, if so then revoke it. - As a fallback to the case when the new access token is not used for an extended period of time, configurable as a setting (ie 1d default), have
cleartokensrevoke it if it's past that configured time period. To be able to determine if this period has passed, an explicitexpiresfield will need to be added on the RefreshToken model.