On Sun, Mar 22, 2009 at 3:37 PM, Nial <nia...@gmail.com> wrote: > > I've been working on some JS that works as an OS X dashboard widget. > The widget connects to a third-party service which requires OAuth > authorization. > > In regards to the Consumer Key/Secret, as far as I understand it, > these two pieces of information (particularly the Secret) are > sensitive and thus should not be shared with anyone. Obviously, the > problem here is that both variables are easily accessible if the user > is to snoop around in the widget's JS files. I'm aware that this is > regularly discussed amongst the OAuth community (and have done some > searches) but wanted to get your opinions. > > On the one hand, it's still more secure than Basic HTTP > authentication, whereby the users credentials are sent, unencoded, > with each and every server request. Similarly, I appreciate that the > Secret key could also be found amongst desktop apps with a bit more > poking and prodding. But on the other, it opens my application to the > possibility of spoofing, whereby a malicious user could use my details > to send nasty requests to the third-party service. > > This opens the question of whether or not to store my consumer key/ > secret within the widgets JS files or request them from a third-party > server as and when the widget is initialized. If I were to do the > former (as I am currently), I'd have to put out a new version of my > widget if my old consumer key/secret were compromised. Which I suppose > begs the question: how often do such things occur? >
I have no idea how often this needs to happen. I would imagine far less often than people playing it up to happen — or worry about it happening — but it's an unsolvable risk if your code is going to be in the clear, so it's a risk that is generally accepted given the alternatives. That said, you could simply watch for nefarious behavior with your consumer key and if you find that it's being used nefarious, just invalidate it but provide a mechanism to politely exchange the old consumer key for a new one, like the way AT&T updates the iPhone: http://www.flickr.com/photos/factoryjoe/3290923828/ http://www.flickr.com/photos/factoryjoe/3290106337 This won't exactly solve your problem, but at least gives you some recourse to force people to update to a new version and perhaps reauthenticate. It won't prevent abuse indefinitely, but it might stem it. The alternative is to put a unique consumer key in each Dashboard Widget download, which is costly from a server side management perspective and doesn't necessarily get you better security — only better visibility into how certain consumers are being used. Depending on your app, it might be worth it. For most, it's probably not worth it. Perhaps other people have more telling experiences/numbers? Chris -- Chris Messina Citizen-Participant & Open Web Advocate factoryjoe.com // diso-project.org // vidoop.com This email is: [ ] bloggable [X] ask first [ ] private --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
