IETF Logo Mail Archive

Re: [OAUTH-WG] Refresh tokens

Kris Selden <kris.selden@gmail.com> Wed, 15 June 2011 19:21 UTC

Return-Path: <kris.selden@gmail.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 A97A821F85D3 for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 12:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 oOYEAiQ9phBO for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 12:21:52 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id C23E821F85CB for <oauth@ietf.org>; Wed, 15 Jun 2011 12:21:52 -0700 (PDT)
Received: by pvh18 with SMTP id 18so641708pvh.31 for <oauth@ietf.org>; Wed, 15 Jun 2011 12:20:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=sxQiINu6DmZWOUx+Xqv7dOA5lBbBGP565pl/xwT67IU=; b=bOfuM3XTYaDwm6nPyKgW8/CxaQZXUiSyXX0fYscV4N6XKdR5eU45I6Rf8ZKBtSB7yL uiQjvLJhXq/LitYl9ldy8QPooKQ/AMfvNMFZK4WlYIntSp1rjUW0Qn56HP6fLYVJV3Hn I7InB15nQdoFGzni62isEHfwj4A9imwq4Uo0U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=PwGMXf0Yy6ozjO165TeFFXraZwEjEctN8zzPPbLJ2jZw8IdLuvxrE+gQXTJdluT+hC v59YtE/7G4pG7Xf4D2pAFRRqAViUxrwJtoAzX4yuGT6PmzllXqTy45hnCdCP7l5VHJ75 ViUrtLJaoEuXus4yLwtsmAWUsX9Ahn6UzcXLM=
Received: by 10.68.9.5 with SMTP id v5mr36135pba.140.1308165625455; Wed, 15 Jun 2011 12:20:25 -0700 (PDT)
Received: from [172.16.176.24] (65-122-179-162.dia.static.qwest.net [65.122.179.162]) by mx.google.com with ESMTPS id x1sm400069pbb.82.2011.06.15.12.20.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2011 12:20:24 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary="Apple-Mail-11--854034262"
From: Kris Selden <kris.selden@gmail.com>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E986B4F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 15 Jun 2011 12:20:47 -0700
Message-Id: <23E83C1C-3874-43D1-A941-F86D79B86B41@gmail.com>
References: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <BANLkTimVQL=4O3=L+et1XSx7-=h4Jnwd+g68siNqpMbSMn_wjA@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234475E986B4F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <eran@hueniverse.com>
X-Mailer: Apple Mail (2.1082)
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:21:53 -0000

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
>

v2.23.0 | Report a Bug | By Email