Re: [OAUTH-WG] Refresh tokens security enhancement

[Allen Tom <[e-mail]>]

Hi Torsten,

Thanks for posting this idea - I think that issuing a new Refresh Token (and
invalidating the old one) on every refresh request would help detect token
theft.

HOWEVER - in practice, this mechanism could make implementations very
tricky. For example, some  applications are highly distributed, with each
instance (or component) having its own copy of the Refresh Token. Keeping
the Refresh Token in sync would not really be feasible for these types of
apps.

Invalidating the Refresh Token (and presumably also invalidating any
outstanding Access Tokens) would make sense as an option for applications
that require a high level of security. However, I do not think that
invalidating the Refresh Token on every Refresh request should be required
in the spec - it should be an implementation specific detail.

At Yahoo, we've used the Refresh Flow for all of our proprietary
authorization APIs for many years, and I know of several applications which
would break if the Refresh Token (and Access Token) were invalidated on
every refresh request. Off the top of my head, I know of server based apps,
mobile apps, and desktop apps which are composed of several components which
asynchronously and independently keep their own copies of the user's
credentials.

Thanks
Allen






On 5/2/10 10:48 AM, "Torsten Lodderstedt" <[e-mail]> wrote:

> We came up with the following idea:
> 
> The authorization server automatically creates a new refresh token with
> every "refresh" request (section 4) and invalidated the previous refresh
> token. The client must use this new token for the next "refresh"
> request. All attempts to obtain access tokens with an invalidated
> refresh token are refused. Additionally, the authorization server should
> hold a history of when the refresh token has been used. The client
> application behavior depends on who uses the refresh token first after
> it has been stolen.