On Tue, 2011-11-15 at 12:41 -0500, John Joseph Bachir wrote: > Thanks Justin - some more questions below... > > What does "public" mean here? In what sense could a client > be > > public or private, and why is implicit grant more > appropriate for the > > public case? > Section 2.1, client types.
> > My understanding of a public client from this section was a client > which is distributed and not hosted on a server, such as a desktop or > mobile app. How is it possible for a web-hosted client to be public? In a JavaScript client, all of the code is distributed to the end user's machine to execute locally, as opposed to a server-side script which only shows the browser its output. In order for JS in the browser to have a secret, the server that hosts the JS would need to spit out the secret along with the code. This secret would likely be the same for every instance of the JS client, and it would be readable by the end user of all of them, which makes it not really a secret and not really very useful. > > > > Step C is the server sending back the HTTP redirect in > response to step > A. Steps D, and E are the user agent following that HTTP > redirect. Step > F is extracting the information from the redirected endpoint. > While the > access token is sent back in step C, scripts running in the > user agent > don't have easy access to it. > > > Ah whoops, I misread C and D. So here's my real question: Why doesn't > the user agent send the access token to the server in D? Why does the > web server have to deliver a script which extracts it locally? Is it > to facilitate a certain style of applications development? 1) The browser generally doesn't send the fragment to the web server 2) That's just standard deployed practice for such JS clients, and it's currently the easiest way for the JS to get a ping that the transaction has completed. -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
