I haven't done much "real" desktop OAuth, mostly web ... but can't you simply proxy the request through your own server, and keep the secret on your server, serving client requests centrally?
Thanks- - Andy Badera - and...@badera.us - Google me: http://www.google.com/search?q=andrew+badera - This email is: [ ] bloggable [x] ask first [ ] private On Sat, Jul 4, 2009 at 4:56 AM, Dossy Shiobara<do...@panoptic.com> wrote: > > Hint: This isn't a dilemma for only open source developers. It's a real and > serious problem for any application whose code (source or object) is > accessible to anyone other than the application developer, > i.e., any application that the user installs. > > It should take all of, what, a day, to create a list of the top 10 desktop > Twitter apps and their corresponding consumer key and secret. > > It's all fun and games until someone discloses a secret. Then, it's just > fun ... > > > On 7/1/09 9:32 AM, Andrew Badera wrote: >> >> The secret should not reside in code. The secret should reside in a >> config file, or maybe even a machine datastore. Abstract it out, no >> one ever needs to see anything secret in your code. >> >> Thanks- >> - Andy Badera >> - and...@badera.us >> - Google me: http://www.google.com/search?q=andrew+badera >> - This email is: [ ] bloggable [x] ask first [ ] private >> >> >> >> On Wed, Jul 1, 2009 at 9:25 AM, DWRoelands<duane.roela...@gmail.com> >> wrote: >>> >>> If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/ >>> core/1.0#anchor4) states it pretty plainly: >>> >>> "Service Providers SHOULD NOT rely on the Consumer Secret as a method >>> to verify the Consumer identity, unless the Consumer Secret is known >>> to be inaccessible to anyone other than the Consumer and the Service >>> Provider." >>> >>> This is exactly what Twitter has done with the Consumer Secret; they >>> rely on it to verify the Consumer identity. >>> >>> This is a thorny dilemma for open source developers. There's no way >>> to share the source code without compromising your application's >>> security, because you've got to include the Consumer Key Secret in the >>> source. You can obfuscate and encrypt, but a malicious actor with >>> access to the source code can simply "step through" the code until the >>> Consumer Secret is exposed in plain text. >>> >>> In any event, what's done is done, and Twitter certainly isn't going >>> to abandon OAuth at this point. But opening the source of my Twitter >>> client seems to be out of the question if I want to use OAuth. >>> >>> >>> On Jul 1, 8:10 am, Philip Plante<pplante....@gmail.com> wrote: >>>> >>>> I do not feel you've made a mountain out of a mole hill here. This >>>> topic has been on my mind since I first encountered oAuth. I haven't >>>> seen any open source apps use oAuth yet. > > > -- > Dossy Shiobara | do...@panoptic.com | http://dossy.org/ > Panoptic Computer Network | http://panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) >
