Re: [OAUTH-WG] user-agent flow needs a rewrite

[Naitik Shah <[e-mail]>]

On Tue, Jul 13, 2010 at 11:17 AM, Brian Eaton <[e-mail]> wrote:

> On Tue, Jul 13, 2010 at 9:42 AM, David Recordon <[e-mail]>
> wrote:
> >> That strikes me as very odd - returning some params in the query, and
> >> others in the fragment is just weird.
> >
> > I actually think that you want this – albiet odd – combination when
> > requesting both a code and token. The code and state parameters are
> needed
> > by the server and thus are query parameters. The access token, scope, and
> > expires in shouldn't be sent to the server via HTTP and thus are within
> > the fragment for the JavaScript to access.
>
> The problem is that if you do it this way you end up busting the
> browser cache.  All of the performance improvements offered by the
> user-agent profile are lost.
>

This is one of the key reasons imho. JavaScript can access the query and the
fragment, so it would technically work in either case. But having the
flexibility to choose where it goes saves on one round trip to the client
application. For instance, in the Facebook SDK we would like to do this
background ping, and save the code in a cookie and fire a JavaScript
callback to let the client application know that one is available. The
client application can then decide if it wants to trigger a network request
to send the code to it's servers, or not. By allowing this data to come in
the fragment, we can use a static endpoint (potentially served from a
subdomain that goes to a CDN) and reduce the process to a single server
request in the common case.


-Naitik