The common OAuth flow inside a mobile app is to show a web browser dialog which loads Webkit/IE/etc and show you the Twitter log-in UI. Frankly, I have no idea how to verify this page is actually Twitter's UI - there is no browser chrome, no SSL lock icon or any other trust indicators. It could as easily be just a random dialog constructed by the app author. I just don't see the value-add of OAuth in mobile app scenarios. Note that xAuth doesn't mean the app stores the passwords - you store a token like in OAuth. Of course, whether the app developer can be trusted to not store the username/password is a different story.
Btw, I have a popular WP7 app which uses xauth, primarily because Twitter's login screen is broken on the Windows Phone browser.
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.
The Twitter OAuth page can't even be scrolled on the WP7 browser.It loads a fuckload of JS. For a page with 2 textboxes and 2 buttons. The Twitter guys are clowns....
Facebook's OAuth flow has the same issue re verifying that its an actual Facebook login. I think browser chrome would go a ways to help me feel its a legit login.
Inside a native app, that's all it would be. A feel good, since I could create the browsery chrome to look however I wanted (e.g. a URL bar that shows twitter.com when the page is mycredsharvest.com).
In theory, Apple could develop some unique chrome for this and then reject any app from the app store that fakes it. That is probably the only way to do this securely with good UX in a mobile app. It's not clear that Apple wants to take on that role though.
You should be able to check whether it actually launches safari, e.g. by pressing the home button and the actually launching safari, should look the same as the screen you just left.
On Linux, even if the Twitter app on your desktop launches a browser, it can still do a very effective job of sniffing your password simply by asking the desktop environment for the relevant events. It only works in the browser because everything is sandboxed, with a particular focus on sandboxed-by-domain. See http://theinvisiblethings.blogspot.com/2011/04/linux-securit... , for instance. There are ways to do that on all the desktop environments, I presume, with varying degrees of officialness and popping up administrator password dialogs.
Btw, I have a popular WP7 app which uses xauth, primarily because Twitter's login screen is broken on the Windows Phone browser.