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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
