As discussed in MDL-59510, there may be cases where the scopes change, causing a new access and refresh token to be requested. This could occur if a user changes the scopes requested for login (via admin -> oauth2 services), or it could happen after a code change, in cases where the scopes for a particular call are hard coded. Either way, in such cases, the stored refresh token for a user with the original scopes would become stale as we'd now be sending requests using the refresh token with the new scopes. Since there isn't a way for us to know when the scope change takes place, we need to consider how to remove these old refresh tokens so they don't just set there in the DB forever.

The approach I suggested over on MDL-59510 was to create a task and look at the last update time on refresh tokens stored in the DB. Any token not edited within the last 6 months or so would be considered stale and purged from the DB. This, of course, won't be able to tell whether a token truly has been replaced by another token more recently, but I think this is still a reasonable way (and time period) in which to roll over the tokens. Any user who hasn't used a token in 6 months probably won't mind re-authorizing the application to which it applies. Any user who is actively using the token, won't have to do anything.