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: mark.mcgl...@ie.ibm.com oauth-boun...@ietf.org wrote on 16/02/2011 21:38:45: > Marius Scurtescu <mscurte...@google.com> > Sent by: oauth-boun...@ietf.org > > 16/02/2011 21:38 > > To > > Eran Hammer-Lahav <e...@hueniverse.com> > > cc > > OAuth WG <oauth@ietf.org> > > Subject > > Re: [OAUTH-WG] Draft -12 feedback deadline > > On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav > <e...@hueniverse.com> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
