Re: [OAUTH-WG] Refresh tokens security enhancement

Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 05 May 2010 19:28 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492E128C17D for <oauth@core3.amsl.com>; Wed, 5 May 2010 12:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.582
X-Spam-Level:
X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_40=-0.185, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-1ohs1EPPRD for <oauth@core3.amsl.com>; Wed, 5 May 2010 12:28:32 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id 5826028C12F for <oauth@ietf.org>; Wed, 5 May 2010 12:28:32 -0700 (PDT)
Received: from p4fff1ebc.dip.t-dialin.net ([79.255.30.188] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1O9kGX-0006nW-4m; Wed, 05 May 2010 21:28:17 +0200
Message-ID: <4BE1C6D0.6010600@lodderstedt.net>
Date: Wed, 05 May 2010 21:28:16 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Marius Scurtescu <mscurtescu@google.com>
References: <C8044E24.2DAD6%atom@yahoo-inc.com> <4BE06831.60105@lodderstedt.net> <AANLkTinfr0-DlgB5rTZYnBhslolxfniVGvhoPY_N6y4Y@mail.gmail.com>
In-Reply-To: <AANLkTinfr0-DlgB5rTZYnBhslolxfniVGvhoPY_N6y4Y@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: 141509
Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Refresh tokens security enhancement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2010 19:28:33 -0000

Am 04.05.2010 21:44, schrieb Marius Scurtescu:
> On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt
> <torsten@lodderstedt.net>  wrote:
>    
>> Am 03.05.2010 18:55, schrieb Allen Tom:
>>      
>>> 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).
>>      
> Torsten, can you please have a look a the "explicit request for
> refresh token" thread?
>
> Would a "refresh_token_type=single" parameter solve the above?
>
>
> Marius
>    

Hi Marius,

I expected the authorization server to decide which kind of token to 
use. Your proposal makes sense as well.
So the client can act according to its security requirements. If the 
authorization server would like to enforce its
own policy, it can detect any mismatch during token issuance.

Nevertheless, support for the optional "refresh_token" response 
parameter of the "refresh" request is the prerequisite.

regards,
Torsten.