Re: [OAUTH-WG] Refresh tokens

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 15 June 2011 19:50 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9952B11E8146 for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 12:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level:
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNqp-L7FeJdZ for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 12:50:17 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 530A211E810D for <oauth@ietf.org>; Wed, 15 Jun 2011 12:50:17 -0700 (PDT)
Received: (qmail 32540 invoked from network); 15 Jun 2011 19:50:14 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 19:50:14 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 15 Jun 2011 12:50:02 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Kris Selden <kris.selden@gmail.com>
Date: Wed, 15 Jun 2011 12:49:42 -0700
Thread-Topic: [OAUTH-WG] Refresh tokens
Thread-Index: AcwrkU2z5htX4wEWT+OhVyydm1Yl8QAAoMNA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986B80@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <BANLkTimVQL=4O3=L+et1XSx7-=h4Jnwd+g68siNqpMbSMn_wjA@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986B4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <23E83C1C-3874-43D1-A941-F86D79B86B41@gmail.com>
In-Reply-To: <23E83C1C-3874-43D1-A941-F86D79B86B41@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234475E986B80P3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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 Jun 2011 19:50:19 -0000

And we need to say that explicitly.

Even if we allow servers to use the two tokens differently, we should clearly state their design considerations and apply any needed restrictions to make that clear. We are leaving way too much to the whims of the individual developer.

Are the access tokens issued using the implicit grant short lived or long lived?
Is it valid to issue valid-till-revoked access tokens alongside refresh tokens?
What are the requirements for allowing resource owners to revoke access, when it comes to issued access tokens and refresh tokens?
Why even issue a refresh token, if the client can authenticate with the authorization server. Why not just include the client identifier and user identifier and let the authorization server lookup what the user already authorized? Yes, this requires different client identifiers for different access rights, but that's easy to do.

There are many more open questions. I have been convinced from reading the last 80 or so messages on the list, that we have given developers too much flexibility. We're at a point where I am no longer sure what's the right way of deploying this. I would like to see use enforce a common-sense approach to deploying these tokens, based on the collective wisdom and deployment experience of this group. We have enough hands-on knowledge to agree on how to narrow this down.

I am not looking for dramatic changes. I'm looking for restrictions. I want the protocol to be more helpful to developers who are not security experts to make the right decisions, and that includes me.

Yes, some use cases will suffer, but that's just what standards are about.

EHL



From: Kris Selden [mailto:kris.selden@gmail.com]
Sent: Wednesday, June 15, 2011 12:21 PM
To: Eran Hammer-Lahav
Cc: Brian Eaton; OAuth WG
Subject: Re: [OAUTH-WG] Refresh tokens

There is a scalability reason, in that the access_token could be verifiable on the resource server without DB lookup or a call out to a central server, then the refresh token serves as the means for revoking in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked."

There is a security reason, the refresh_token is only ever exchanged with authorization server whereas the access_token is exchanged with resource servers.  This mitigates the risk of a long-lived access_token leaking (query param in a log file on an insecure resource server, beta or poorly coded resource server app, JS SDK client on a non https site that puts the access_token in a cookie, etc) in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked" vs "an access token good-till-revoked without a refresh token."

On Jun 15, 2011, at 11:56 AM, Eran Hammer-Lahav wrote:


Yes, this is useful and on my list of changes to apply.

But I would like to start with a more basic, normative definition of what a refresh token is for. Right now, we have a very vague definition for it, and it is not clear how developers should use it alongside access tokens.

EHL