[OAUTH-WG] explicit request for refresh token

Marius Scurtescu <mscurtescu@google.com> Tue, 04 May 2010 18:49 UTC

Return-Path: <mscurtescu@google.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 8382528C1E1 for <oauth@core3.amsl.com>; Tue, 4 May 2010 11:49:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.363
X-Spam-Level:
X-Spam-Status: No, score=-100.363 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 EdnEOgxMfHU8 for <oauth@core3.amsl.com>; Tue, 4 May 2010 11:49:27 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 33D7528C1E7 for <oauth@ietf.org>; Tue, 4 May 2010 11:41:50 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [10.3.21.3]) by smtp-out.google.com with ESMTP id o44IfYRw003502 for <oauth@ietf.org>; Tue, 4 May 2010 11:41:35 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1272998495; bh=pgexjv0uBe36Shx9L/QCMOcvbBk=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=ZFjNlvhuR9WIRedHmfKSp9y5vi3YQJGM43WMZf3X285U7ObPHYE8rGLxajkFCiWEN fu4RTTGT2O6r20KUXLqgw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type:x-system-of-record; b=NNNaQlANIeeTARxRyQ1/5n9pb/1S04giUTqkchacspc/BdvQJYt52UKcU0vX4SX1V X0awthJh+0dAvh2lLslRg==
Received: from pzk34 (pzk34.prod.google.com [10.243.19.162]) by hpaq3.eem.corp.google.com with ESMTP id o44IfWgX031000 for <oauth@ietf.org>; Tue, 4 May 2010 11:41:33 -0700
Received: by pzk34 with SMTP id 34so2142971pzk.33 for <oauth@ietf.org>; Tue, 04 May 2010 11:41:32 -0700 (PDT)
Received: by 10.141.91.13 with SMTP id t13mr4857695rvl.266.1272998492083; Tue, 04 May 2010 11:41:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.14.15 with HTTP; Tue, 4 May 2010 11:41:12 -0700 (PDT)
From: Marius Scurtescu <mscurtescu@google.com>
Date: Tue, 04 May 2010 11:41:12 -0700
Message-ID: <AANLkTikGnNa2PN_CzUd_cxkji2octA9C8QprBo3AlJrK@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Subject: [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: Tue, 04 May 2010 18:49:28 -0000

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