Re: [OAUTH-WG] Draft -12 feedback deadline

Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 01 March 2011 20:01 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 5383C3A6A2D; Tue, 1 Mar 2011 12:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.206
X-Spam-Level:
X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 OTUKeMKa2M8j; Tue, 1 Mar 2011 12:01:13 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) by core3.amsl.com (Postfix) with ESMTP id 989D03A6AA9; Tue, 1 Mar 2011 12:01:12 -0800 (PST)
Received: from [79.253.34.196] (helo=[192.168.71.49]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1PuVlt-00059l-Iz; Tue, 01 Mar 2011 21:02:13 +0100
Message-ID: <4D6D50C5.4040703@lodderstedt.net>
Date: Tue, 01 Mar 2011 21:02:13 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Marius Scurtescu <mscurtescu@google.com>
References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimjWkO8o+z+P=AKpyYkSjTh6oS7uM9N0JwR_vR6@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTi=tvwsR=_EhPRkYEwC+ERwRCNN2aAWDqRDvwx8B@mail.gmail.com> <FFDFD7371D517847AD71FBB08F9A315638493F514F@SP2-EX07VS06.ds.corp.yahoo.com> <AANLkTimxhoK1vt8HwSF9dvu4Z5xjqrLLb2SULj9pp=9b@mail.gmail.com> <AANLkTi=DtgpWNyEKBg=0GhOWuqSvzF5q0SJQgfZNRm8M@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTindJ3oGpggvZ7jRJ4TRhTRomyZG+DwLOfbHD2kq@mail.gmail.com> <OFEFAF96E1.1837BBD4-ON8025783B.0040108E-8025783B.0040FF69@ie.ibm.com> <AANLkTi=PnOmyaMnNrGgPnOO_wtF8b_=v99wiR5ospHLH@mail.gmail.com> <4D68F471.3090204@lodderstedt.net> <4D6C0289.3030300@alcatel-lucent.com> <AANLkTi=GK2Lrb_snOenhiCPxdqL85VHqLyp4Y1_aCCdp@mail.gmail.com>
In-Reply-To: <AANLkTi=GK2Lrb_snOenhiCPxdqL85VHqLyp4Y1_aCCdp@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: torsten@lodderstedt-online.de
Cc: OAuth WG <oauth@ietf.org>, oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
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: Tue, 01 Mar 2011 20:01:14 -0000

Am 28.02.2011 23:58, schrieb Marius Scurtescu:
> On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg
> <igor.faynberg@alcatel-lucent.com>  wrote:
>> +1
>>
>> Igor
>>
>> Torsten Lodderstedt wrote:
>>> ...
>>>
>>> I'm in favour to add the refresh token parameter to the implicit grant
>>> flow as it would make it more useable for native apps.
> I think it is much safer to go with refresh tokens only sent
> indirectly through an authorization code swap.
>

why is it _much_ safer? The only threat elimimated by this approach is a 
token leak via browser cache. On the other hand, the authorization code 
flow has to be protected from session fixation and guessing attacks, 
threats which are not applicable to the implicit grant flow.

It seams to be acceptable to issue access tokens with the implicit grant 
but not refresh tokens. Why? Because we assume access tokens have a much 
sorter lifetime than refresh tokens? This is not specified by the draft! 
So anyone could issue access tokens with infinite lifetime via the 
implicit grant and claim full OAuth 2.0 compliance.

> Implicit grant with refresh token also has no client secret swap and
> makes things worse by passing the refresh token through the browser.

What do you think is the value of having a client secret for a native app?

As pointed out in my previous posting, refresh tokens can be invalidated 
during every refresh request. So the impact can be reduced to that of an 
access token leak (which seams to be acceptable).

regards,
Torsten.

> Marius