On Tue, May 31, 2011 at 10:41 AM, Chuck Mortimore <[email protected]> wrote: > Updated in language I just sent out – thanks. > > On that note, we currently return refresh_token using the implicit grant > type under certain controlled circumstances. Facebook in turn uses the > implicit grant type, and simply issues long term access_tokens. > > Are there any strong objections to adding optional support for > referesh_token on the implicit grant along with security considerations?
Is that really necessary? Why? The justification of reduced network round trips seems bogus to me. We're talking about clients that just loaded up an entire web page, asked the user to login, picked up a redirect, and are about to make at least one and possibly several other API calls. I'd prefer to keep the spec simple and consistent. We can add all kinds of options and maybes to the language, but long-term it will just hurt interop. I'd rather settle on protocol flows that make sense. One risk that comes up with returning refresh tokens with the implicit grant type involves recovering from compromise of client web servers. That's not strictly relevant to the current distinction (we're talking about installed apps, different threat model), but it might be worth thinking about anyway. Consider what happens when a client web server is compromised and the client secret and refresh tokens are stolen. - the attacker can use the tokens until the compromise is discovered. - the client secret is then changed - the stolen refresh tokens then become useless Now, *if* the implicit grant type returns refresh token, that story changes. Even if the client secret is changed, the attacker can keep using the refresh tokens! They do it by passing them to the victim client again, through the implicit grant flow. The victim client will then link the refresh token to the attacker's account. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
