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

Justin Richer <> Fri, 16 January 2015 13:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9806D1ACE01 for <>; Fri, 16 Jan 2015 05:37:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q1U-MYxjj_zn for <>; Fri, 16 Jan 2015 05:37:44 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 930B21ACDFC for <>; Fri, 16 Jan 2015 05:37:44 -0800 (PST)
X-AuditID: 12074423-f797b6d000000cfe-9b-54b914275eea
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 5E.06.03326.72419B45; Fri, 16 Jan 2015 08:37:43 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t0GDbgbN015762; Fri, 16 Jan 2015 08:37:42 -0500
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t0GDbdqb030752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 16 Jan 2015 08:37:40 -0500
Message-ID: <>
Date: Fri, 16 Jan 2015 08:37:33 -0500
From: Justin Richer <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Amit Gupta <>, "" <>, "" <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040602050103080108060101"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUixG6nrqsusjPEYOYlMYsZZx6zWdw6u4bJ 4uTbV2wWn2/PZbZ4dewpiwOrx4ePcR4LNpV6LFnyk8nj3uEbTB7HevpZA1ijuGxSUnMyy1KL 9O0SuDJu75zEVtA+ibHi4oklTA2MT+q6GDk5JARMJGa0/GaEsMUkLtxbz9bFyMUhJLCYSWLD tUZWCGcjo8S7o6+gnNtMEosOnWEHaeEVUJM4uPAnmM0ioCrxftU0ZhCbDcievqaFCcQWFYiS mH3+AStEvaDEyZlPWEBsEYFzjBJzj7iB2MxA9etXXwSrFxaolTjU9wxsppBAkMTZTzvAzuMU CJbYcP41M0R9mMTZl81sExgFZiEZOwtJCsK2lbgzdzczhC0v0bx1NpStK7Fo2wp2ZPEFjGyr GGVTcqt0cxMzc4pTk3WLkxPz8lKLdM30cjNL9FJTSjcxgqPFRXkH45+DSocYBTgYlXh4Z2zZ ESLEmlhWXJl7iFGSg0lJlNdMaGeIEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeDAGgHG9KYmVV alE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBC+fMFCjYFFqempFWmZOCUKaiYMT ZDgP0HB7kBre4oLE3OLMdIj8KUZFKXFeBZCEAEgiozQPrheWzF4xigO9IsxbDlLFA0yEcN2v gAYzAQ3Of7wDZHBJIkJKqoGR486f2l1Hj7retM1gMuY9dyv/3NUdt6NubFlo8kNTquneuky9 +TNZUmqVJ5VmSZcrLHkd22WsK/L0xVneO1rfbq1jjju0/p5fdpgSu+2W0IdntgnOL3y4R2vL WysNl5glbKmadhnCrd2d+x1suxedi/32P9NWasadmSeSG30nPH9qPZl5kXO6EktxRqKhFnNR cSIA8CUQYkEDAAA=
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens
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 13:37:52 -0000

This seems to be more of an implementation of revocation and handling 
refresh token lifetimes than anything that the spec would talk about. In 
what's described below, it doesn't seem that the client ever specifies 
the threshold, nor would the AS desire the client to do so. This is all 
something that can happen server-side, out of the view of the client.

In other words, I don't (personally) see what would have to change in 
the RFC for someone to implement this scheme. Can you please clarify 
what I'm missing?

  -- Justin

On 1/16/2015 3:39 AM, Amit Gupta wrote:
> 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 clt^th     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 5^th    (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.
> --
> Thanks,
> Amit
> _______________________________________________
> OAuth mailing list