My understanding is that it is considered a best practice to rollover a refresh token on each use - that is when a refresh token is used, both a new access token and a new refresh token are issued, and the old refresh token is revoked.
The primary reason I have seen cited for this is it would allow for the detection of a compromised refresh token (cloned client for example). If the legitimate client is not the first to use their refresh token it will fail when they do eventually try to use it. The likelihood of such a scenario or other implications of a lost refresh token is a different debate. Ideally the timeouts on the messages and the transport used for the refresh token exchange should be "reliable". If that is not the case then a mechanism such as suggested by Brian is possible, but ultimately not very clean as it means you really need to maintain at least two valid refresh tokens concurrently per initial grant and it gets messy. For example extending Brian's scenario, what would you do in response to #4? Return the same refresh token as #2? Return a new one and invalidate the one returned in response #2? From a server-side perspective you don't really know what the "right" thing to do is as you don't know the true state of the client. I would be inclined to optomise for the normal case and provided the error rate wasn't too high simply require a new initial grant when the app's refresh token gets out of sync. If the error rate is very high then I would consider a non-OAuth-standards-based more reliable transport mechanism for refresh token flows from the mobile, perhaps with a trusted piece of intermediary infrastructure to interface with the real authorization server using a standard flow. Regards, Shane. From: Tim Bray <[email protected]> To: Brian Eaton <[email protected]> Cc: OAuth WG <[email protected]>, Bob Gregory <[email protected]> Date: 27/11/2012 12:53 PM Subject: Re: [OAUTH-WG] Token refresh and The Two Generals Sent by: [email protected] As I read back through this one I’m not getting why you need a new refresh token. What am I missing? -T On Mon, Nov 26, 2012 at 6:27 PM, Brian Eaton <[email protected]> wrote: On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory <[email protected]> wrote: We've had OAuth2 running successfully for a while now, but we're finding that mobile applications have frequent problems with the refresh flow where a refresh request is made, but the network connection fails before the new AT/RT pair is received, leading to a "lost grant". In server-logs we can see that the token has been refreshed, and a new RT issued, but the client is stuck with the old invalidated RT. This problem has been reported by two separate client applications, both of whom are using a retry-mechanism for API requests since they expect an unreliable network connection. Does anybody have any guidance on this issue, or is there any work in an extension to address the issue of lost grants for token refreshes? Have you considered not revoking the old RT until the new RT has been successfully used? You might also need to consider what happens with requests that are in-flight at the time the old RT is revoked. For example: 1) client starts token exchange, hangs for some reason. 2) client starts token exchange, succeeds, receives new refresh token 3) client uses new refresh token 4) request 1 completes That could all happen in the space of a second or two. So you might want to think about not revoking the old token until you see the new refresh token used and a bit of time has passed. Cheers, Brian _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
