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?


On Jun 24, 12:04 am, Jef Poskanzer <> 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.

Reply via email to