> > The real trick was what to do with keys in an open source app, but > > fortunately the key issue is already solved because Twitter is presumably > > not relying on oauth_consumer_key to unambiguously or securely identify > > consumer clients, > > But then how could Twitter revoke access for a rogue app? I thought > the point of the app keys *is* to identify the app itself. > Also for Open Source apps, their keys are going to have to be locally > accessible, so now anyone could see the secret key.
I thought so as well, but from section 4 of the OAuth Core 1.0 spec: "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. The Consumer Secret MAY be an empty string (for example when no Consumer verification is needed, or when verification is achieved through other means such as RSA)." So the fact that situations exist where consumer keys cannot be considered secure is considered in the OAuth spec. This was something Blaine set me straight on. My guess is Twitter will deal with rogues on a token-by-token basis rather than a consumer key basis. As they (and I, and others) have been saying all along, OAuth isn't insurance against bad apps, it's insurance against bad apps having your password. Authorizing a bad app still allows it to do bad things, but at least now you can revoke only that app's access token and not affect other apps. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- BOND THEME NOW PLAYING: "The Living Daylights" -----------------------------
