Sure, that's an option, but not one which I would likely take, for multiple reasons, including rate limiting which I would like to apply to my client (my server is whitelisted so all accounts would suddenly get 20000 -> that's a bad idea).
I was wondering how the "big" clients do this, like TweetDeck, Twitter for iPhone, Gwibber, DestroyTwitter, TwitterBerry, etc. Is their key storage so secure that they have never had a key leak, or do they implement oAuth differently? I doubt that all of their requests go via a server... Also, I know that this may sound a bit stupid, but I'd like to propose a change in oAuth (1.1?) so that it's no longer needed to supply both keys. Where can I do this? Tom On Jun 24, 12:04 am, Jef Poskanzer <jef.poskan...@gmail.com> wrote: > You're right in theory that requests after the initial authentication > step should not really need the app's credentials, a single > authentication token & secret ought to suffice and the service > (twitter) should remember which app each token came from. But shrug, > that's just not the way OAuth works. It's not twitter's fault, they > are just following the spec. I can't even say it's particularly > unreasoinable - flickr's similar three-party authentication protocol > is much simpler than OAuth but it still uses the app key on every > request. > > As for embedding the app secret in desktop and mobile executables and > trusting that it will be just too difficult for miscreants to extract, > I say don't do it. The OAuth RFC says so too. Keeping the secret in > a server-side proxy is probably the best solution.
