Re: [OAUTH-WG] explicit request for refresh token

Eran Hammer-Lahav <eran@hueniverse.com> Sun, 09 May 2010 21:00 UTC

Return-Path: <eran@hueniverse.com>
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 4B50E3A6902 for <oauth@core3.amsl.com>; Sun, 9 May 2010 14:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.545
X-Spam-Level:
X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_20=-0.74]
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 ZVvLYTzRd9Fx for <oauth@core3.amsl.com>; Sun, 9 May 2010 14:00:54 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 664CE3A6800 for <oauth@ietf.org>; Sun, 9 May 2010 14:00:49 -0700 (PDT)
Received: (qmail 2707 invoked from network); 9 May 2010 21:00:36 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 May 2010 21:00:36 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 9 May 2010 14:00:36 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Marius Scurtescu <mscurtescu@google.com>, OAuth WG <oauth@ietf.org>
Date: Sun, 09 May 2010 14:00:36 -0700
Thread-Topic: [OAUTH-WG] explicit request for refresh token
Thread-Index: Acrrun//xuKHNFDdQJOXmw2+pNS59AEAAvsA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <AANLkTikGnNa2PN_CzUd_cxkji2octA9C8QprBo3AlJrK@mail.gmail.com>
In-Reply-To: <AANLkTikGnNa2PN_CzUd_cxkji2octA9C8QprBo3AlJrK@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] explicit request for refresh token
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: Sun, 09 May 2010 21:00:55 -0000

Seems like extra complexity for little gain. The only benefit is saving server resources when a refresh token isn't going to be used by the client, but since most clients are likely to use it, the saving isn't much.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Marius Scurtescu
> Sent: Tuesday, May 04, 2010 11:41 AM
> To: OAuth WG
> Subject: [OAUTH-WG] explicit request for refresh token
> 
> Currently all flows return an optional refresh token and I think it was
> mentioned that the Autonomous Client flows should never return a refresh
> token.
> 
> While a refresh token will probably be used in most cases by the other flows,
> in some cases the refresh token will be just ignored by the client. Ideally in
> these cases the refresh token is not issued at all.
> 
> Also, Torsten suggested that when a new access token is requested then
> also a new refresh token is issued, this would allow the authorization server
> to detected if a refresh token was leaked and used by an attacker. However,
> this will not work in all cases.
> 
> I suggest we add a parameter to the requests that normally issues the
> refresh token as a hint to the authorization server that the client wants a
> multi-use, single-use or no refresh token at all. This will be just a hint, the
> authorization server can decide how to proceed.
> 
> For example, this parameter could look something like:
> - refresh_token_type = [none | multi | single]
> 
> The default would be "none". "multi" is the normal refresh token and
> "single" is the refresh token suggested by Torsten.
> 
> If the server does not support "single" type refresh tokens then it will issue a
> regular token and when the access token is renewed then it will not send a
> new refresh token. If for a certain flow or client the authz server does not
> want to issue refresh tokens at all then it can ignore the refresh_token_type
> request and just not issue one. If "multi" is requested then either "multi" or
> "none" should be issued.
> 
> This refresh token type request parameter could be implemented as an
> extension as well.
> 
> Thoughts?
> 
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth