----- Original Message ----
> From: Luke Shepard <lshep...@facebook.com>
> If you want to send an access token directly to the server, we have the web
>server flow designed to do that. The JS redirect or Ajax call is just a more
>complicated way to send the token to the server. The user-agent flow is
>intended for use where the resource needs to be accessed directly from the
>client - either in Javascript, or a mobile or desktop application.
>
We're not discussing web server profile here and my objective is not to send an
"access token directly to the server", but to eliminate secrets in URL.
> OAuth 2.0 merely codifies what is already standard industry practice -
>Facebook, Twitter, Google, OpenSocial, and others rely on this cross domain
>technique in order to transfer access tokens within a client-only context.
>
I would not mix the existing implementation and the standard. Standard could
and
should be more generic. The wording around UA flow is generic enough, but it
has
one implementation specific feature - sending access token in a URL's fragment.
I don't understand why it should be there. I think nobody will argue, if I say
that there are other ways of transferring access tokens between parties
involved. I've even provided one example where URL's fragment is not used. I
didn't hear yet why it wouldn't work. I might have missed some important steps
in that example, but I think, if mistakes or omissions do exist, they can be
easily fixed by adding extra steps and probably even extra round trips to a
third party server (sorry, Brian).
Here is my final proposal in regards of UA profile.
Let me try to re-write steps C to E in a way that will not break the existing
implementations, but at the same time will leave some room for other
implementations:
(C) If the end-user granted access, the authorization server
will issue an access token and pass it to the user agent.
(D) The user-agent will use the access token granted by the
authorization server to get access to a protected resource
on the resource server.
> On Aug 3, 2010, at 8:56 PM, Oleg Gryb wrote:
>
> >
> >
> >
> >
> >> From: Brian Eaton <bea...@google.com>
> >> HTTP/1.1 302 Moved Temporarily
> >> Location: http://www.thirdparty.com/rpc_relay.html#access_token=12345
> >
> >>
> >> rpc_relay.html is highly cached in the browser, so instead of
> >> incurring hundreds of ms to fetch a file, the data lands in the
> >> third-party.com javascript in under a millisecond.
> >
> > I see your point, but let me try to eliminate the call to rpc_relay.html
> > at
>all.
>
> > After all, the ultimate goal is not to receive an access token, but a
>resource
>
> > protected by that token. If there are mistakes in the suggestion below,
>please
>
> > let me know what they are.
> >
> > Let us assume that the response contains this instead of the Location
>header:
> >
> > <HTML>
> > <HEAD>
> > <script>
> > function process(token, url) {
> > document.params.setAttribute("method", "POST");
> > document.params.setAttribute("action", url);
> > document.params.submit();
> > }
> > </script>
> > </HEAD>
> > <BODY
> >
>onload="process(document.params.access_token.value,document.params.url.value)">
> > <form name="params">
> > <input type="hidden" name="access_token" value="12345"/>
> > <input type="hidden" name="url"
> > value="http://resourceserver.com/protected_resource.html"/>
> > </form>
> > </BODY>
> > </HTML>
> >
> > Access token will be sent directly to the service provider. There is no
> > need
>to
>
> > call rpc_relay.html. There is no need to call that complicated cross
> > domain
> > communication logic described at FB. There is no need to create cookies.
> >
> > You can do Ajax as well:
> >
> > <HTML>
> > <HEAD>
> > <script>
> >
> > function process(token, url) {
> >
> > xmlhttp=new XMLHttpRequest();
> > params ="access_token="+token+"&....";
> > xmlhttp.open("POST", url, true);
> > xmlhttp.onreadystatechange = ...
> > xmlhttp.send(params);
> > }
> > </script>
> > </HEAD>
> > ...
> >
> > Is there anything wrong with either of these approaches?
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
