Marius Isn't the risk of the refresh token leaking the same as the risk of the access token leaking, i.e. why not provide both? IMO, the refresh token just provides a server side mechanism for revoking access, where resource servers are distributed, through having short lived access tokens
Of course, the refresh access token flow currently requires a secret so would need to be changed or alternative flow introduced. Will wait for details of how auth code flow can be used Mark e-mail: [email protected] [email protected] wrote on 16/02/2011 21:38:45: > Marius Scurtescu <[email protected]> > Sent by: [email protected] > > 16/02/2011 21:38 > > To > > Eran Hammer-Lahav <[email protected]> > > cc > > OAuth WG <[email protected]> > > Subject > > Re: [OAUTH-WG] Draft -12 feedback deadline > > On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav > <[email protected]> wrote: > > The reason why we don't return a refresh token in the implicit > grant is exactly because there is no client authentication... > > Not sure that's the main reason. AFAIK it is because the response is > sent through the user-agent and it could leak. > > > > These are all well-balanced flows with specific security > properties. If you need something else, even if it is just a tweak, > it must be considered a different flow. That doesn't mean you need > to register a new grant type, just that you are dealing with > different implementation details unique to your server. > > The Authorization Code flow, with no client secret, is perfectly fine > for Native Apps IMO. > > Marius > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
