On Mon, Jul 12, 2010 at 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." > > 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. Brian, can you tell me what you mean by cryptographically implemented refresh token, and why using one would be crazy? You say using them would require server-side state. I'd say just the opposite. If you *are* signing your refresh tokens (a cryptographic operation) you don't need to store them on the auth server, but if you aren't using cryptography, then you must store the tokens on the auth server in order to validate them when they come back to you. So in short, I'm thinking the opposite of what you state. So please enlighten me. What am I missing?
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
