Twitter Requiring OAuth for Direct Messages
I can’t think of any reason why Twitter would force native apps through OAuth other than to create a hurdle that steers users toward Twitter’s own official native clients. Because Twitter’s official clients aren’t going to force users to jump through OAuth to authenticate — they’re still going to simply ask for your username and password in a simple native dialog box.
Time to be frank: any security that OAuth claims – with respect to native applications – is an illusion. If a native app wants to get a copy of your password, it will get a copy of your password. If it wants to hijack the authentication process, bring up a bogus “browser” for you to enter a password into, register keyloggers, muck with your system web proxy settings and sniff passwords before they hit the wire, or phish you some other way, guess what: it can and it will. OAuth does not solve these problems. It just adds complexity to the login process.
Update (2011-05-19): Macro Arment:
Oh, and one more thing: formerly-xAuth apps that need DM access have only 12 days to build this completely new login interface, test it, and release a new version — and, for iOS and Mac App Store apps, get it approved — before their existing apps start being denied access to DMs and probably display confusing and incorrect error messages, since the developers could never have foreseen this condition. Such aggressive timing is definitely a dick move.
Twitter has since extended the deadline to June 14, but that’s still rather short notice.
3 Comments RSS · Twitter
The quoted blogs are off-base on many points.
The goal of using OAuth in native apps is not to protect against malice of those native apps. Rather, it accomplishes these things:
- Avoids the need for apps to store the user's password locally on the device, and instead lets apps store just a limited-scope, revocable token
- Avoids the need for apps to implement support for all the present or future security features needed by the service (perhaps with captchas, second-factor authentication such as by mobile phone, and so on)
OAuth 1 is complex and fragile, though unfortunately it is what Twitter still relies on; OAuth 2 is easier for apps to support.
Service providers do need to ensure that their sign-in UI really is suitable for use in installed apps and on mobile devices, but that is unrelated to the value of OAuth as a standard sign-in mechanism.
@grobbins If you’re going to say they’re off-base, please provide specifics. It was Twitter itself that brought up the idea of protecting you from malicious apps. xAuth could already store a token rather than the password, so that is not an advantage of OAuth. Support for future security features is possibly useful but not a benefit that Twitter claimed, nor a good reason to drop support for xAuth on such short notice.
Gruber says, "So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth", but that ignores the additional kinds of authentication that OAuth enables. He also asserts, "not only do you need to go through the cumbersome OAuth login process for each additional account, but you must first sign out of the Twitter account you’re already signed into in the web browser", but that's not true for embedded OAuth implementations that clear out the site cookies before signing in.
Brichter asserts incorrectly that OAuth requires the user be sent to an external browser, and also states that it is "time to be frank: any security that OAuth claims – with respect to native applications – is an illusion", again missing the goal of enabling clients to transparently use whatever evolving security the site considers necessary.
OAuth and OAuth 2 are certainly inadequately designed for use in installed apps, and most sites providing OAuth sign-in offer disappointing user experience for installed app. And Twitter's policies are open to debate.
But OAuth does offer substantial value and the foundation of a better model for client authentication than do less flexible username & password schemes. And given the myriad ways that passwords can be filched, the sooner sites move away from reliance on them, the better.
