[OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens

Amit Gupta <amit.gupta@insideview.com> Fri, 16 January 2015 08:39 UTC

Return-Path: <amit.gupta@insideview.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E725B1A0194 for <oauth@ietfa.amsl.com>; Fri, 16 Jan 2015 00:39:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7XzHUR8_F1Qn for <oauth@ietfa.amsl.com>; Fri, 16 Jan 2015 00:39:10 -0800 (PST)
Received: from server506.appriver.com (server506i.appriver.com []) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846501A6F2D for <oauth@ietf.org>; Fri, 16 Jan 2015 00:39:10 -0800 (PST)
X-Note-AR-ScanTimeLocal: 1/16/2015 2:39:08 AM
X-Policy: insideview.com - insideview.com
X-Policy: insideview.com - insideview.com
X-Policy: insideview.com - insideview.com
X-Policy: insideview.com - insideview.com
X-Primary: amit.gupta@insideview.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Note: SecureTide Build: 11/21/2014 10:58:18 PM UTC
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-85/SG:5 1/16/2015 2:38:56 AM
X-GBUdb-Analysis: 1,, Ugly c=1 p=-0.9966 Source White
X-Signature-Violations: 0-0-0-22755-c
X-Note: Spam Tests Failed:
X-Country-Path: UNKNOWN->PRIVATE->United States
X-Note-Reverse-DNS: smtp.exg6.exghost.com
X-Note-Return-Path: amit.gupta@insideview.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G251 G252 G253 G254 G258 G259 G371
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 139610586; Fri, 16 Jan 2015 02:39:08 -0600
Received: from DAGN10A-E6.exg6.exghost.com ([]) by HT03-E6.exg6.exghost.com ([]) with mapi id 14.03.0210.002; Fri, 16 Jan 2015 02:39:08 -0600
From: Amit Gupta <amit.gupta@insideview.com>
To: "torsten@lodderstedt.net" <torsten@lodderstedt.net>, "mscurtescu@google.com" <mscurtescu@google.com>, "sdronia@gmx.de" <sdronia@gmx.de>
Thread-Topic: RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens
Thread-Index: AdAxZRlLaRyw+19oS/CIjljjczH2vw==
Date: Fri, 16 Jan 2015 08:39:07 +0000
Message-ID: <EC5D50A28C853445B767C0962CAD45720F7F1E3C@DAGN10a-e6.exg6.exghost.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_EC5D50A28C853445B767C0962CAD45720F7F1E3CDAGN10ae6exg6ex_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/E60iF12UhSvaX6y3Zqa5mOaKyY8>
X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:18 -0800
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 16 Jan 2015 08:40:59 -0000

Hi Torsten, Stefanie, Marius

I wanted to suggest an addition to the token revocation rfc7009 to provide more clarity on how revocation of refresh tokens should be handled. I feel the rfc should,

1. Describe how the client/resource-owner can provide "standing instructions" to the OAuth server to revoke refresh tokens.

2. Describe the default way to for the OAuth server to define constrains for revocation of refresh token if this constrains are not specified by the client/resource owner.

The way it could be handled is:

1. Store a Client level threshold (clt) of number of valid refresh tokens per "user-client" combination (and OAuth server can store the default value for clt, if undefined by the client or resource owner).

2. Keep the "time to live" for the access token reasonably small (few minutes to couple of hours).

a. Revocation of active token removes the token ad the refresh token.

b. When new tokens are generated, up to "clt" number of Refresh tokens is maintained by the OAuth server (the most recent refresh token over writes the cltth  refresh token for user-client combination).

c. Revocation of inactive token removes the refresh token.

We have implemented such a scheme for our OAuth server, whereby "clt" is set to five by default (if not specified in client the properties). Therefore,

1. Whenever a new token and refresh token is created, it overwrites the 5th (clt=5) oldest refresh token (for clientId-userId combination).

2. Code grant tokens are only valid for 1 hour. When the token expires, refresh token is not removed.

3. When an "active" token is revoked, Token and it's refresh token is also revoked.

4. When an "expired" token is revoked, only the corresponding refresh token is revoked.

The above example explicitly specify how to handle revocation of refresh tokens when the client has not informed the OAuth server about how expiry of refresh tokens should be handled. This also allows clients to specify certain constrains (like default time to live for tokens, and client level threshold for number of refresh tokens to keep active for each client-user combination).

Are you planning to update the RFC on the scheme to handle revocation of refresh token? If not, would you be willing to include the proposed changes to RFC7009? Please let me know.