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
