Subject: Re: [OAUTH-WG] issuing new refresh tokens

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 2 Sep 2010 10:11:53 -0700

Is this reasonable?

"The authorization server MAY
            issue a new refresh token, in which case, the client MUST discard the old refresh
            token and replace it with the new refresh token."

This is as much consensus as I was able to extract.

EHL

-----Original Message-----
From: Torsten Lodderstedt [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2010 2:33 PM
To: Brian Eaton
Cc: Kris Selden; Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] issuing new refresh tokens

>
> On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt 
> <[email-masked]>  wrote:
>    
>> We plan to issue new refresh tokens for certain clients only (mobile, 
>> desktop), it's part of the client-related policy. So the behavior for a particular client is predictable.
>>      
> Nice.
>
> Would you be willing to expand on the current spec language a bit, to 
> explain the use cases, and offer more normative language about how 
> clients should handle refresh token exchange?
>
> This is a cool feature, but the current language is kind of vague.
>
> Cheers,
> Brian
>    

I'm not sure what you would like me to write. But let's get started:

We expected the clients to discard the old refresh token and to use the newly issued refresh token instead. The old refresh tokens is revoked instantly. Any attempt to use it afterwards is interpreted as a potential misuse because the assumption would be that an adversary has copied the token or cloned the device. The client should notify the user of the problem and recommend him/her to check its application authorizations (refresh tokens) in our user self care portal. There, the user will have acces to information on when the token has been used the last time and therewith detect any odd behavior. The user could then revoke the token and/or alarm its providers helpdesk.

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 02 Sep 2010 19:42:09 +0200

+1

---

From: Stefanie Dronia <[email-masked]>
Date: Fri, 03 Sep 2010 09:23:42 +0200

+1

Am 02.09.2010 19:42, schrieb Torsten Lodderstedt:
>> We expected the clients to discard the old refresh token and to use 
>> the newly issued refresh token instead. The old refresh tokens is 
>> revoked instantly. Any attempt to use it afterwards is interpreted as 
>> a potential misuse because the assumption would be that an adversary 
>> has copied the token or cloned the device. The client should notify 
>> the user of the problem and recommend him/her to check its 
>> application authorizations (refresh tokens) in our user self care 
>> portal. There, the user will have acces to information on when the 
>> token has been used the last time and therewith detect any odd 
>> behavior. The user could then revoke the token and/or alarm its 
>> providers helpdesk.
>>
>> regards,
>> Torsten.
>>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Ebling, Sebastian" <[email-masked]>
Date: Fri, 3 Sep 2010 11:26:29 +0200

+1

This is not too complicated for the client but improves security.

regards

Sebastian Ebling

> From: Stefanie Dronia [mailto:[email-masked]] 
> Sent: Friday, September 03, 2010 9:24 AM
> To: [email-masked]
> >>>> We plan to issue new refresh tokens for certain clients only 
> >>>> (mobile, desktop), it's part of the client-related 
> policy. So the 
> >>>> behavior for a particular client is predictable.
> >>>>
> >>> Nice.
> >>>
> >>> Would you be willing to expand on the current spec 
> language a bit, 
> >>> to explain the use cases, and offer more normative language about 
> >>> how clients should handle refresh token exchange?
> >>>