On Thu, May 27, 2010 at 11:06 AM, Nat Sakimura <[email protected]> wrote: > On Fri, May 28, 2010 at 2:10 AM, Marius Scurtescu <[email protected]> > wrote: >> Thanks for the clarification Nat. >> >> Just curios, can't the phone client actually POST to the authz server? >> That would take care of the URL length limitation. > > POST means an extra click, which is a UI disaster.
I assume self posting forms do not work on these devices? > Also, more data over the air means slower response. True, but the alternative is to have the authz server fetch the data from the web client, some cycles are lost there as well. >> In your diagram, the verification code is passed from UA to Web Client >> and then the Web Client is exchanging it for the access and refresh >> tokens. These tokens are never passed back to the UA, is that >> intended? Also, why can't the UA do the exchange directly? > > It is following the Web Server flow. > Apart from getting the request parameter through the request_url fetch > is almost exactly as in the Web Server flow. Sure, but who is the client in this case? Isn't the UA (aka phone) ultimately interested in having access tokens so it can make API calls? Marius _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
