Torsten Lodderstedt [OAUTH-WG] Refresh tokens security enhancement http://www.ietf.org/mail-archive/web/oauth/current/msg02292.html
Eran Hammer-Lahav Re: [OAUTH-WG] Refresh tokens security enhancement http://www.ietf.org/mail-archive/web/oauth/current/msg02390.html On Jul 13, 2010, at 7:04 AM, Eran Hammer-Lahav wrote: > > > > On 7/12/10 10:36 PM, "Brian Eaton" <bea...@google.com> wrote: > >> Draft 10 has the following sentence in section 4.1.4: >> http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4 >> >> "The authorization server MAY issue a new refresh token." > > The capability was there since -02. > > -04 added the following text in an attempt to clarify how the refresh_token > output can be used (returning a refresh token was briefly discussed as part > of the general idea of always allowing a refresh token in token responses): > > The authorization server > MAY issue a new refresh token in which case the client MUST NOT use > the previous refresh token and replace it with the newly issued > refresh token. > > In -10 I dropped the restriction because people expressed a general issue > with having to revoke tokens. > >> That carries a surprising amount of baggage. I suggest removing the >> sentence, or changing it to MUST NOT, pending a discussion of the use >> cases for issuing new refresh tokens. >> >> Does anyone remember why that sentence got added to the spec? >> >> There are two reasons I can see for issuing new refresh tokens: >> 1) secrets are like underwear, change them frequently >> 2) someone has a cryptographically implemented refresh token that >> needs to be re-signed or re-issued >> >> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, >> these pretty much have to be backed by server-side state or there is >> no way to run your system. So I'm going to ignore that possibility, >> and guess that someone was interested in changing secrets... > > There was no requirement to support changing refresh tokens. If there is no > interest in this, I suggest we forbid it (otherwise all clients will need to > accommodate the chance of a new refresh token, and then will need guidelines > on how to handle it). > >> So if we want to issue new refresh tokens because we like to change >> secrets, we should cover: >> - whether existing refresh tokens are revoked. (I'd vote for MUST be >> revoked) > > I agree. > >> - the minimum latency between issuing a new refresh token and revoking >> the old one. (I'd vote for minimum latency measured in hours or >> longer. Clients that have cached refresh tokens need to refresh their >> cache within this time period, or they're borked.) >> - the maxium latency for revoking the old token. (I'd vote for >> maximum latency measured in hours or days, just for security reasons. >> But I can't think of what would break if servers ignored this advice.) > > Why is this required? Can it be specified as a general recommendation? > > EHL > >> Cheers, >> Brian >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
