Re: [OAUTH-WG] User-Agent flow and refresh tokens

[Marius Scurtescu <[e-mail]>]

On Sun, Sep 19, 2010 at 7:29 AM, Torsten Lodderstedt
<[e-mail]> wrote:
>  Am 16.09.2010 21:35, schrieb Marius Scurtescu:
>>
>> On Thu, Sep 16, 2010 at 12:00 PM, Torsten Lodderstedt
>> <[e-mail]>  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