On Sun, Sep 19, 2010 at 7:29 AM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Am 16.09.2010 21:35, schrieb Marius Scurtescu: >> >> On Thu, Sep 16, 2010 at 12:00 PM, Torsten Lodderstedt >> <tors...@lodderstedt.net> wrote: >>> >>> I don't know whether I understand you correctly. Are you saying that >>> refresh tokens only make sense in Web servers? >> >> I was referring to the "web server" flow/profile. Not web servers in >> general. >> >> Why would a native app use the user-agent flow (response_type=token) >> over the web server flow (response_type=code)? > > The draft mentions both options > (http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-1.4.3) and also > states: > > "Embedded user-agents often offer a better end-user flow, as they remove the > need to switch context and open new windows."
Embedded user-agent does not mean user-agent profile. The client can embed the browser (aka user-agent) and then use either the web server (response_type=code) or the user-agent (response_type=toke) profiles. "user-agent' is used in two totally different (and orthogonal) contexts. > Luke Shepard also indicated in his posting > http://www.ietf.org/mail-archive/web/oauth/current/msg03509.html that > facebook supports the user agent flow for desktop applications. Facebook's > iOS SDK seems to use the same technique for mobile apps. Yes, Facebook is recommending the User-Agent flow for desktop applications. This works for them because access tokens issued by Facebook are not short lived, I don't think they expire. The desktop app does not need a refresh token. If the authz server is issuing short lived access tokens and also refresh tokens then the user-agent profile does not work so well anymore. As far as I can tell in this case there is no reason to use this profile with desktop apps, just use the web server profile. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
