We plan to issue new refresh tokens for certain clients only (mobile, desktop), it's part of the client-related policy. So the behavior for a particular client is predictable.
Regards, Torsten. Am 14.07.2010 um 03:07 schrieb Brian Eaton <bea...@google.com>: > Kris - > > Thanks for pointing back to where this started! > > I more or less agree with what Allen said in response to Torsten's > proposal: http://www.ietf.org/mail-archive/web/oauth/current/msg02295.html. > The devil is in the details. > > I'd be interested in tackling client secret rotation at the same time > as handling refresh token rotation... they are similar problems. > > BUT, if we do this, we should do it reasonably well. In particular, I > think we'd need: > - a way for clients to opt-in to this, probably when they first get a > refresh token > - a system that worked for distributed clients > - a system that allowed rotation of the client secret > > I don't think any of that would be impractical, long-term. Windows > and AD have had automatic rotation of kerberos service keys for a > while, for example. > > And here's a more far-fetched idea... installed applications could > self-generate public/private key pairs, which could then be used to > authenticate to the authorization server using something like Yaron's > recent proposal for client assertion authentication. > > Cheers, > Brian > > On Tue, Jul 13, 2010 at 5:55 PM, Kris Selden <kris.sel...@gmail.com> wrote: >> 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
