If the security model of Oauth was to actually separate your provider login from the requesting app, then as far as I can tell the model fails in all cases since the app is always expected to be the one that opens the application/browser window and that's never good security.
But what I thought was the case was that the Oauth model was just a cumbersome fig leaf allowing an application to say it never touches the users password. That is a benefit in the sense of protecting an application from itself (a well-intentioned application doesn't have to store its users password).
If Twitter really wanted to separate application authentication from Provider authentication, they could do something like have the app send you a message in twitter from which you could give it permissions OR they could give you a series of "application passwords" which you could then give to the applications (one password per privileged level, each password stays valid till you revoke one application's privilege).
Either of those would be both secure and reasonably simple BUT since it requires the user's mind to think two steps ahead, it would make the apps a harder sell and so you've got the present fake security...
The alternative is to display the Twitter URL that the user must go to to authorize the app. Then have them copy-paste the credentials back into the app. I.e.:
Go to this url to authorize app:
http://twitter.com/auth?token=blah
Please input credentials: [__________]
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.
If my app hosts the browser control, then there's nothing stopping me injecting custom javascript into the page to listen for input events.
Not to mention having to store the key / secret in the app (unless you use a proxy).
OAuth fails for mobile.