Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E725B1A0194 for ; 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-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XzHUR8_F1Qn for ; Fri, 16 Jan 2015 00:39:10 -0800 (PST) Received: from server506.appriver.com (server506i.appriver.com [50.56.144.147]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846501A6F2D for ; 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, 169.254.1.45, 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-Sending-IP: 10.242.229.139 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 [10.242.229.139] (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 ([169.254.1.45]) by HT03-E6.exg6.exghost.com ([50.56.144.21]) with mapi id 14.03.0210.002; Fri, 16 Jan 2015 02:39:08 -0600 From: Amit Gupta To: "torsten@lodderstedt.net" , "mscurtescu@google.com" , "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: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [209.61.191.156] x-rerouted-by-exchange: Content-Type: multipart/alternative; boundary="_000_EC5D50A28C853445B767C0962CAD45720F7F1E3CDAGN10ae6exg6ex_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 05:31:18 -0800 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 08:40:59 -0000 --_000_EC5D50A28C853445B767C0962CAD45720F7F1E3CDAGN10ae6exg6ex_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 instruction= s" to the OAuth server to revoke refresh tokens. 2. Describe the default way to for the OAuth server to define constrains fo= r revocation of refresh token if this constrains are not specified by the c= lient/resource owner. The way it could be handled is: 1. Store a Client level threshold (clt) of number of valid refresh tokens p= er "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 minut= es 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 m= aintained by the OAuth server (the most recent refresh token over writes th= e 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 se= t 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=3D5) oldest refresh token (for clientId-userId combination). 2. Code grant tokens are only valid for 1 hour. When the token expires, ref= resh 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 to= kens when the client has not informed the OAuth server about how expiry of = refresh tokens should be handled. This also allows clients to specify certa= in constrains (like default time to live for tokens, and client level thres= hold for number of refresh tokens to keep active for each client-user combi= nation). Are you planning to update the RFC on the scheme to handle revocation of re= fresh token? If not, would you be willing to include the proposed changes t= o RFC7009? Please let me know. -- Thanks, Amit --_000_EC5D50A28C853445B767C0962CAD45720F7F1E3CDAGN10ae6exg6ex_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi Torsten, Stefanie, Marius 
 
I wanted to suggest an addition to the token revocation rfc7009 t=
o provide more clarity on how revocation of refresh tokens should be handle=
d. I feel the rfc should,
1. Describe how the client/resource-owner ca=
n 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 constr=
ains 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 vali=
d refresh tokens per “user-client” combination (and OAuth serve=
r can store the default value for clt, if undefined by the client or resour=
ce owner). 


2. Keep the “time to live” for t=
he access token reasonably small (few minutes to couple of hours). 


a. Revocation of active token removes the to=
ken ad the refresh token.


b. When new tokens are generated, up to R=
20;clt” number of Refresh tokens is maintained by the OAuth server (t=
he 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 &=
#8220;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=3D5) oldest refresh token (=
for clientId-userId combination). 


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



3. When an “active” token is rev=
oked, Token and it’s refresh token is also revoked. 


4. When an “expired” token is re=
voked, only the corresponding refresh token is revoked. <=
/pre>

 


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 spe=
cify certain constrains (like default time to live for tokens, and client l=
evel 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 revoca=
tion of refresh token? If not, would you be willing to include the proposed=
 changes to RFC7009? Please let me know.


--


Thanks,


Amit


 
--_000_EC5D50A28C853445B767C0962CAD45720F7F1E3CDAGN10ae6exg6ex_--