We did consider holding on to two refresh tokens, but it rapidly gets messy and degrades to using a single refresh token: since the old token won't be invalidated until the new one is used, a client can continue to use the old token indefinitely.
After hurried conversation, we've decided that we will allow mobile clients to use a long-lived refresh token that does not expire on each request. This isn't our preferred option, since we have no way of detecting a compromised RT, but in order to obtain the RT an attacker must either a) Intercept the token in-flight by a MITM attack over SSL, which is non-trivial, or b) Obtain physical access to the client device, in which case it's game over anyway. We'll probably revisit this decision when we come to do another round of work on authentication, but for now this solves a user-experience issue that we're seeing in the wild, without seriously affecting real-world security. Thanks for your comments, I'll let you know if we find a way to de-messify the two-token solution. Yours, -- Bob. On Tue, Nov 27, 2012 at 3:22 AM, Shane B Weeden <swee...@au1.ibm.com> wrote: > 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 <twb...@google.com> > To: Brian Eaton <bea...@google.com> > Cc: OAuth WG <oauth@ietf.org>, Bob Gregory <pathoge...@gmail.com> > Date: 27/11/2012 12:53 PM > Subject: Re: [OAUTH-WG] Token refresh and The Two Generals > Sent by: oauth-boun...@ietf.org > > > > 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 <bea...@google.com> wrote: > On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory <pathoge...@gmail.com> > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Q. How many members of a demographic group does it take to perform a specified task? A. A finite number; one to perform the task, and the remainder to act in a manner stereotypical of the group in question.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
