I read an article documenting Twitter abruptly pulling its OAuth support back in April 2009. The article said it wouldn't specify the hole for security reasons, but mentioned "social engineering" is involved.
I'm guessing that the hole is that a malicious site can pretend to be using OAuth, and redirect the user to a phishing site meant to mimic Twitter in an attempt to get their username and password. Is this correct?
Additionally, whatever the flaw is, how is it being addressed in 2.0?
The April 2009 "session fixation attack" is described here: http://oauth.net/advisories/2009-1/ and in more detail here: http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/
Security means different things from different perspectives. As I keep repeating on this site, it all depends on your threat model. Application providers have a different threat model than users, which is different than the RIAA's.
There is a movement among some OAuth 2.0 users from crypto signatures to a "wrap" model: "bearer tokens wrapped with TLS" (like cookies). The editor of the spec talks about his concerns with that for interoperable discovery scenarios: http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/ In Draft 11 of the OAuth 2.0 spec the option for signatures is back in. The bearer token spec is moved out to a companion spec, and there are also companion specs for signatures via SAML and Kerberos. Perhaps there will be others (like the OAuth 1.0 scheme?) See the decision and thinking at http://www.ietf.org/mail-archive/web/oauth/current/msg04573.html
See also another earlier comment: http://benlog.com/articles/2009/12/22/its-a-wrap/
Here is another discussion of how it can get messy dealing with the different security perspectives.
http://benlog.com/articles/2010/09/02/an-unwarranted-bashing-of-twitters-oauth/
