On 2010/05/28, at 3:12, Marius Scurtescu <mscurte...@google.com> wrote:
On Thu, May 27, 2010 at 11:06 AM, Nat Sakimura <sakim...@gmail.com>
wrote:
On Fri, May 28, 2010 at 2:10 AM, Marius Scurtescu <mscurte...@google.com
> 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?
Unfortunately, not.
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.
The server to server connection generally is much faster.
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?
The UA on these devices are generally dumb. Generally speaking, we
want the the web client to all the job and get only the summary to the
UA.
Marius
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
