Exactly OAuth works well on the web when the requesting application doesn't have control of the browser.
In any situation where the requesting application controls the browser you may as well just hand it your password.
In any situation where the requesting application controls the browser you may as well just hand it your password.
Go to this url to authorize app:
http://twitter.com/auth?token=blah
Please input credentials: [__________]No - I'm not serious. The idea is horrible..
But my point is that Oauth doesn't work for security against malicious apps any--fricken--where. Not on the desktop, not on the web, NOWHERE.
The model of one web page opening another web page "for your convenience" is the model of bank phishing spam attacks. You don't control the browser if another page has opened the browser for you. And unless my research terribly misguided, Oauth absolutely requires the initial app's web page to be the actor which opens the authorization page (Oauth 1.1 requires the whole 'handshake' process to happen fairly quickly for God-knows-what-pseudo-security-reason). What's the user's reaction to entering credentials to twitterauthorizationtimstamp.com? "Sure, that makes sense..."
Oauth is like "electronic checks" signed with Photoshop - its a fig leaf of security. It's not entirely bad but it certainly doesn't deliver what it sort-of seems to be trying to deliver.