Actually, this is one of the approaches we've considered. This issue most commonly occurs when an end-user is moving from 3G to wi-fi, or from an active mobile connection to a zero-signal area.
If we recycle refresh tokens less frequently (after, say, 24 hours) then the client application will be able to retry the refresh once their connection is reliable again, but we keep most of the advantage of refresh-token revocation. The trade-off is that it's more of a pain to build this way, and we're in an awful hurry :) -- Bob On Tue, Nov 27, 2012 at 8:10 PM, Brian Eaton <bea...@google.com> wrote: > On Mon, Nov 26, 2012 at 7:22 PM, 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. >> > > FWIW, I think rotating the refresh token every time it is used is a bit > excessive, something time based (e.g. once every few weeks or few months) > would be fine as well. > > The trade-off is that things that happen rarely are more likely to trigger > bugs on the client side. =) > -- 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
