[OAUTH-WG] Refresh tokens

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 15 June 2011 17:30 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 2ECB221F85CF for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 10:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level:
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.085, 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 DPdFfZCXyy2x for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 10:30:53 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id C045321F85CE for <oauth@ietf.org>; Wed, 15 Jun 2011 10:30:53 -0700 (PDT)
Received: (qmail 26792 invoked from network); 15 Jun 2011 17:30:52 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 17:30:52 -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 10:30:47 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: Wed, 15 Jun 2011 10:30:27 -0700
Thread-Topic: Refresh tokens
Thread-Index: AcwrgXObqVi9qhn3QCOgElgVMivvNw==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
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_90C41DD21FB7C64BB94121FBBC2E7234475E986AF9P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: [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 17:30:59 -0000

The main source of confusion about refresh token is caused by the protocol lack of clear definition of access token lifetime, even in relative terms, and the objectives of refresh tokens. For example, the authorization server can issue:

- an access token good for an hour, with a refresh token good for a year or good-till-revoked
- an access token good-till-revoked without a refresh token
- an access token good-till-revoked with a refresh token, used to obtain additional access tokens for a distributed environment

In large scale systems access tokens are often self-describing, including all the information needed by the resource server to validate them. In such a setup, access tokens cannot be revoked until expired. Refresh tokens on the other hand, require a database lookup for the resource owner grant, and can be revoked.

The only real difference between the implicit and authorization code grant types is the inclusion of a refresh token. The point is not to issue long term credentials without client authentication, relying on the presence of the resource owner for authenticating the client. However, we don't say that anywhere, or define the goals of the two token types design with enough detail to offer sound security.

I would like to add a quick discussion of access token and refresh token recommended deployment setup, providing clear guidelines when a refresh token SHOULD and SHOULD NOT be issued, and when issues, how it is difference from the access token.

It's time we stop trying to accommodate every possible combination and make some hard choices.

EHL