Re: [OAUTH-WG] Refresh tokens security enhancement

[Torsten Lodderstedt <[e-mail]>]

Hi Allen,

Am 03.05.2010 18:55, schrieb Allen Tom:
> 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.
>    

You are right, this approach might make implementing a client more 
difficult, especially clustered web applications.
That's not the case for autonomous devices (gaming consoles, mobile 
phones e.t.c) where the application
architecture will typically be much simpler. On the other hand, these 
are exactly the clients where the current
version of the specification does not contain any countermeasure against 
token theft.

> 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.
>    

It could be an optional feature of the spec (as many other features). An 
authorization server could decide
when to use it based on its policy. For example, the authorization 
server could make this decision
depend on client type (mobile vs. web application), client id, or target 
service (security level).

The definition could be as follows

  refresh_token
          OPTIONAL.  A new refresh token replacing the refresh_token 
used as input parameter.
          If set, the client must use this token for the next "refresh" 
request. The former refresh
          token has been invalidated by the authorization server.

The benefit of making it an (optional) spec feature is support by 
libraries, standard service and
applications. From my point of view, OAuth2 has the potential to become 
THE standard for
securing standard protocols like IMAP, SyncML, SIP, WebDav and many 
others. Every feature
defined by the standard is most likely supported by standard clients and 
servers. So depending
on the authorization servers policy, all of this clients could be 
secured with the proposed
countermeasure.


> 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.
>    

As I said, it could be an optional feature, which offers out of the box 
token theft prevention. Every
deployment can decide to use it or not.

The proposed change is small in terms of specification but we could 
demonstrate that OAuth is also
suited for applications with a higher level of security.

regards,
Torsten.

> 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.
>>      
>