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

[Torsten Lodderstedt <[e-mail]>]

  Am 20.09.2010 07:34, schrieb Luke Shepard:
>> 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.
>> >  
> That's true. Although code_and_token is intended to solve that - you get the access token in the response, and then you can use the code to exchange for a refresh token on the server side if you need longer term access. There's no reason for a user agent to ever have a refresh token (since the performance optimization doesn't make sense when you are refreshing after an expiration period)
>

Sorry for being persistent, but I want to understand what the benefit of 
the user agent flow is. I'm assuming their is a benefit beyond 
supporting JavaScript clients. But this benefit is not really 
transparent to me. And by the way, that was one of the questions raised 
(and not completely answered) at IETF 78.

In my understanding of all the discussions on the list, the major 
difference to the web server flow is that the client does not need to 
have an active server side in order to obtain tokens, just a static 
responder page. Tokens are directly transfered on the (HTTPS protected) 
direct communication link to the authorization server, which also result 
in performance and load optimizations.

Why doesn't it make sense to obtain refresh tokens that way while it 
make sense to issue long-living access tokens?

Would you please comment?

regards,
Torsten.