[OAUTH-WG] User-Agent flow and refresh tokens

Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 15 September 2010 21:47 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 A607E3A6A86 for <oauth@core3.amsl.com>; Wed, 15 Sep 2010 14:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.146, 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 FAHvHABl1EIb for <oauth@core3.amsl.com>; Wed, 15 Sep 2010 14:47:00 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id ADBF73A6A80 for <oauth@ietf.org>; Wed, 15 Sep 2010 14:47:00 -0700 (PDT)
Received: from p4ffd2609.dip.t-dialin.net ([79.253.38.9] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1Ovzp6-0002H8-4k for oauth@ietf.org; Wed, 15 Sep 2010 23:47:24 +0200
Message-ID: <4C913EE3.90704@lodderstedt.net>
Date: Wed, 15 Sep 2010 23:47:15 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: 141509
Subject: [OAUTH-WG] User-Agent flow and refresh tokens
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, 15 Sep 2010 21:47:01 -0000

  I'm wondering whether it makes sense to allow for the issuance of 
refresh tokens by the user-agent flow.

Background of my considerations is the development of applications on 
mobile devices (apps :-)). The draft suggests to either use the web 
server or the user agent flow for the integration of such applications 
with an OAuth authorization server. For sake of user experience, I would 
expect mobile applications to use refresh tokens instead of sending the 
user through the authorization on every application start. I also would 
assume that the mobile client does not use a client secret because it 
cannot really protect it from recovery. Instead, token theft could be 
encountered by replacing refresh tokens with every request to the tokens 
endpoint.

This scenario is feasable with the web server flow but not with the 
user-agent flow. This is because the later does only support the 
issuance of access tokens. In previous discussions this has been 
motivated by the weaker security (missing client authentication) of the 
user-agent flow. But as pointed out above, the web server flow can (and 
will be) used w/o client secret, too.

So why don't we allow for the  issuance of refresh tokens by the 
user-agent flow?

regards,
Torsten.