On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloin <mark.mcgl...@ie.ibm.com> wrote: > 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?
Sure, but refresh tokens never die. > 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 The flow is not changing. For native apps the client secret can either be declared optional, or a "well known secret" can be issued for native apps. The authorization server can also insist that each native app has a unique secret and it must guard it, that may or may not make sense. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
