You can still use the access code (web server) flow within a JavaScript application, just without a reliable client secret. The point of the "implicit" flow was to save a roundtrip to the server for light clients with limited lifespans, and it's a tradeoff between security, ease of implementation, and performance.
-- Justin On Wed, 2011-07-06 at 16:08 -0400, Kushal Dave wrote: > Hello! > > > Foursquare recently encountered a scary example of a client > accidentally leaking user tokens as part of the implicit grant flow. > It turns out the official "Tweet this" button provided by twitter > grabs the URL, including fragment, at the time of page load, before > the client's Javascript has had a chance to elide the access_token > hash value. And it's easy to imagine lots of other sharing and > analytics tools could be similarly aggressive in transmitting hash > values outside of the page. > > > We've thought a lot about what to do about this, short of disabling > the flow entirely. One thing that seems viable is to make the "access > token" in this flow actually a one-time use token. The requesting page > would then make a JSONP request exchanging the one-time use token for > a permanent token that is never visible in the URL. Has this come up? > Have you had any feedback from other implementors? > > > We're not excited about such a blatant deviation from the spec, but > we're not sure what else to do. > > > Cheers, > Kushal _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
