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.
I'm OK with requiring OAuth. It's hard to trust third parties with data they collect themselves: see Sony and Gawker. It's even harder to trust them with data that belongs to someone else: they might one-way-hash their own passwords, of course, but they can't do that to your Twitter password. It's probably sitting in a database, cleartext, for every rogue employee or cracker to see.
Even if you don't care about someone having your credentials, you can't trust them not to intentionally or accidentally misuse your account. The only way to trust a third party is to give them an account that can only perform the actions that you specify, and that's exactly what OAuth does. Of course you have to use Twitter's site for that: that's where the trust comes from.
Anyway, I've used Android apps that pop open a web browser for the authentication part and then return you to the native app. It's, by definition, not seamless... but it's not confusing or slow or difficult or annoying. I imagine the experience is similar on iOS and Blackberry. So I don't see a problem here: all I see is the ability for users to have better protection over their personal information. That means they will be more willing to try your product, because the damage it can cause is limited. Less risk, more opportunity for innovation.
> I'm OK with requiring OAuth. It's hard to trust third parties with data they collect themselves: see Sony and Gawker. It's even harder to trust them with data that belongs to someone else: they might one-way-hash their own passwords, of course, but they can't do that to your Twitter password. It's probably sitting in a database, cleartext, for every rogue employee or cracker to see.
That's a load of FUD crap the OAuth and OpenID projects perpetuate. If you can't trust the 3rd party then why the hell are you logging in? If it's a matter of "they might get hacked" then why is Twitter suddenly special and is somehow magically more safe? Trust me, based on what I hear Twitter is not more safe than Gawker. How is a more complicated login system safer? More complicated things like OAuth are not safer, they're just more complicated.
The entire security premise of OAuth is junk. It's only advantage is that Twitter/Facebook/Google become the owners of your users and can leverage that against you or the other site. It's just idiotic to say that the only way to secure your access to SuperHackable.com is to go through Twitter.com as if that makes SuperHackable.com better or that Twitter.com has some sort of magic super powers.
If you can't trust the 3rd party then why the hell are you logging in?
Well, you can't really trust any third parties. So, to minimize exposure, you want to trust as few of them as possible. Now, obviously the Sony incident shows us how trusting big companies is not a good idea, but in general, bigger companies are going to try harder to protect your data because they have more to lose. Your weekend project has nothing to lose if it starts spamming my Twitter followers. But I really didn't mean to bring up this particular topic; I apologize.
I'm discussing OAuth in the context of allowing applications to do stuff to your Twitter account, not to authenticate you as you. So Twitter isn't owning your users, you are merely allowing users to delegate their Twitter permissions to you on a fine-grained basis. This is nice because it allows, say, an app to read my public tweets, but not to send them. Giving an app my password means it can do anything, and all I can do is change my password (killing all legitimate apps, too) if it does Something Bad. I think we can agree that that's sub-optimal.
I personally will not use apps that require me to use a third party to create an account. I don't mind running my own OpenID server, though, or delegating it if I'm feeling lazy. I do mind being locked into someone else's platform forever.
Giving less than 2 weeks notice qualifies as a "shit sandwich". Not to mention that OAuth does not prevent any native client from getting your credentials via the web view they pop-up. It is a poor decision for native apps as it does not increase security, disables features for a time (until new version approved), makes for a bad ui experience, and gives the illusion of better security.
As the maker of an iOS Twitter client that used to use OAuth (now uses xAuth), I can tell you it's trivial to retrieve the user's username and password from the embedded UIWebView. If someone wants to steal user credentials, they'll still be able to.
Twitter created xAuth; no one forced it on them. It's odd that they would remove it now when they could have moved everyone to the web workflow when they transitioned away from basic auth.
When one further considers that they're giving developers only 2 weeks to comply, it's hard to escape the feeling that this isn't really about security and is more about tightening the noose on third-party developers.
Intentional malice will get you banned from the App Store, so there are incentives not to do it. Accidental stupidity ("our database got hacked") won't.
So if you actually want to protect your users, you can now take yourself out of the loop. If you want to fuck over your users, well, you've always been able to do that and you still can do it.
> So if you actually want to protect your users, you can now take yourself out of the loop.
That doesn't even begin to make sense for a native client. Insofar as it comes to security, trust, and data storage, the native client is the user, and they can't be taken out of the loop.
This differs quite a bit from a web service, which is a situation in which OAuth actually makes sense.
I think jrockway is saying that because with Oauth, you shouldn't normal have a users password at all, if a user's password leaks from a given app then the app author won't have an excuse and thus would be banned from the app.
Oauth doesn't protect the user from malcious apps but it protects the user from dumb app and it keeps apps from "playing dumb" when they give info to a third party.
On the other hand, I know nothing of Xauth. It too may allow you not to save passwords.
> I think jrockway is saying that because with Oauth, you shouldn't normal have a users password at all, if a user's password leaks from a given app then the app author won't have an excuse and thus would be banned from the app.
While I understand what he's saying, I don't think the risk assessment makes any sense. When is the last time you heard of a native application leaking passwords in a way that made them accessible to someone who didn't already have access to your desktop or mobile phone?
> On the other hand, I know nothing of Xauth. It too may allow you not to save passwords.
With xAuth, you exchange the user's username and password for a revokable authentication token. The application can then use that token for future requests, discarding the provided username/password.
> it keeps apps from "playing dumb" when they
> give info to a third party.
What companies are giving out usernames and passwords to 3rd parties, and then trying to 'play dumb?' It seems to me like you're talking about companies that sell your email address to 3rd parties, but that's a whole different ballgame. At the risk of venturing off into bad analogy land, you're claiming that companies are giving away the keys to your house (to 3rd parties), when you really mean that they're giving away your mailing address (to 3rd parties).
I agree, this is a little dramatic. Another thing I'd point out is that the author is putting way too much emphasis on the login part of the experience. Is OAuth seamless? Clearly not. But it works, and it's a one-time thing. If you want to improve the user's experience, and you're harping on OAuth, you're implying that everything else the user touches is perfect. Amdahl would be disappointed.
Everything else the user touches, natively, has the potential to be perfect. The developer has direct control. OAuth's shitty UX is permanent and immutable – and completely jarring as an introduction to a new user.
The trouble with OAuth is it presents a broken/oddly decoupled interface at the most delicate moment - when the user has only just chosen to use the application.
For tech people it is not seamless,
For non-tech people it is worse than 'not seamless', it is entirely confusing.
Couldn't agree more. As much as I dislike Gruber's style (all snark, all the time) the man is intelligent. How he does not see that less sharing of credentials equals better security is beyond me. This is clearly a security win. Definitely a usability loss but welcome to infosec. That is the battle.
How is it a security win in a native app? The app controls the web view and can get at the password. It is the illusion of security with the added confusion of acting different than other services (like e-mail).
Quite right. I was momentarily blinded by the idea of being able to grant specific access rights to specific applications without giving them password access, but clearly if they control they web view you are doing this by, not much has been gained.
OAuth makes sense for browser based applications/access from one web application to another. It makes no sense for native apps since those can still grab your credentials in a wild variety of ways.
If you agree with that, then you should see that the change from
"Choose xAuth or OAuth, based on preference and usage"
to
"Use OAuth unless you are the official Twitter client, if it makes sense or not"
These two arguments are separate. A malicious app that steals credentials (wait, in Gruber's world these apps are vetted, right?) is going to steal credentials whether it uses xauth or oauth. A non malicious app that uses xauth could in theory be exploited to reveal credentials whereas if it just used oauth it wouldn't be an issue of the same magnitude. It is a security win. You can argue the magnitude of the win all you want.
My understanding is that inorder for a developer to receive an xAuth application key, they have to first be vetted by a representative from twitter. This involves exchanging information regarding a summary of the app, how it will be using the API, etc. So there is still some existing measure of security regarding xAuth, although not nearly as much oauth.
Yes, browsers can be broken, SSL can be broken, and Twitter can auction off your credentials to the higest bidder.
But more likely, someone's written-in-a-weekend throwaway app will simply be insecure and eventually unmaintained, and OAuth protects you from that. That means you can safely use someone's written-in-a-weekend throwaway app without having to change your password when you get bored.
If someone comes to your house with rubber hoses and hits you with them until you start posting "i love being hit with rubber hoses" to twitter, well... that's outside the scope of OAuth. So are malicious web browsers and malicious CAs.
Not sure if this would break some TOS or something but can't a native app just continue asking you for your username and password and just do this oath stuff in an offscreen webview, making it seem just like with xauth? It's almost disingenuous to show an in app browser with oath and confuse the user into thinking he has the same sort of "same origin" security as oath in the browser -- he doesn't, that webview is completely controlled by the app and thus offers no additional security over xauth whatsoever.
About 3 years ago I was working for an internal team at eBay to create an app for their end users. Their api uses OAuth for all public resources. Instead of going through the pain of getting access to private apis, we just built the app on top of the public apis. Being perceived as a normal eBay product though we didn't want end users going through the Oauth process so we just processed the flow in a hidden webview. It was the path of least resistance that still allowed us to look official.
From a technical perspective, what you're talking about is something that would be very brittle and liable to break because of changes Twitter make to their login pages.
It's also relying on functionality that may be treated in the future as an attack vector and locked down by either Apple or Twitter. e.g. like the changes a lot of web browsers made to cross-domain ajax posts, pop-ups, pop-unders, etc.
Everything you are describing being "locked down" happened within the context of the browser world, not to webviews you control. Again, once you are in control of the webview you can do anything. Think of this way: you could just implement your own HTML renderer, at which point, once again, nothing anyone builds in will matter. In fact, why bother embedding a webview at all? Depending on how they implemented the login, simply download the HTML source code as plaintext, then issue the post of the form yourself -- no browser required. Each of these is slightly more abstracted, but you get the idea.
I agree with your point that this may be brittle, but that's kind of the point I'm making -- you're getting zero new security benefits out of it and introducing the possibility that many apps use a worse technique to get what they want done. Also, if you are just manually filling out a form I wouldn't worry about brittleness too much, you're just looking for two text fields and then submitting whatever form contains them yourself. Unless Twitter actively starts trying to create fake form elements or something I doubt anything would break, and even then, is this really what Twitter wants to get in the business of building, tricky forms to swat third party apps?
As many others have pointed out, OAuth is extremely susceptible to phishing or snooping of passwords on platforms where the OAuth flow is done in an embedded web view, which can be considered "untrusted", vs. your browser which could be considered "trusted" because you know the URL bar is accurate, and there's no mechanism for 3rd parties to scrape passwords (well, except for user scripts / extensions)
OAuth does also remove the burden of securely storing passwords, but so does xAuth.
Of course, OAuth is also vulnerable to phishing in a "trusted" browser, when you're talking about average users who don't really understand how it works.
One interesting way to provide "trust" would be to have a system wide "OAuth" view (or, "secure browser," or whatever you want to call it). It would have to contain some piece of user information, like say your user account name and photo, that the app itself is never granted access to. That way, if you're actually paying attention you can verify that the system displayed this view.
It would have to contain some piece of user information, like say your user account name and photo, that the app itself is never granted access to.
A security seal, defined by the user (one time operation). Yahoo used to have this, and so does my bank in the login page. May be some text, a doodle or picture.
Curiously, Wikipedia only seems to know about physical seals. Searching for "security seal login" yields some info.
These never seemed very secure to me for the reason mentioned in that article:
The obvious flaw in the design is that a phishing site can get the correct SiteKey info from the genuine site, then serve it to the user, "proving" its legitimacy[1]. SiteKey is thus susceptible to a man-in-the-middle attack.
But at least it requires the attacker to connect to the website, which gives them opportunity to block hosts that are known or suspected to be phishing users.
And of course that vulnerability would not exist here, in that the information would not web accessible, but rather only accessible to the local operating system.
"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" > I think this nails it.
At what point is someone going to just say "fuck Twitter, Inc." and create a library of simple web-scrapers that emulates most of the API that twitter has been trying to claw back from the third-party dev community for the past year via the standard http interface? Such a library may be brittle, but it can't be much worse than the "yeah, we told you to do this a couple of months ago but now we changed our minds and you have two weeks to comply with our new policy" status that exists now?
On a related note. Did anyone else notice today's removal of the "status" query string variable and the switch solely to "Web Intents"? http://dev.twitter.com/pages/intents. I believe many Twitter sharing buttons used the simpler query string approach over the full API with OAuth.
It's clear that Twitter wants to move innovation in their ecosystem away from native clients that duplicate their exiting functionality. Instead they seem to be keen to support projects that offer innovative ways of displaying, sorting, or working with Twitter's firehose.
Instagram does something similar. Their API terms of use read:
"You cannot replicate the core user experience of Instagram.com"
(http://instagram.com/developer/)
I guess it is a matter of keeping potential future monetization options.
So pretty much a shit sandwich from Twitter. The thing is Twitter probably would not have been nearly as successful without all the 3rd party mobile apps, and now Twitter is screwing with the people that contributed to Twitter's own success.
I wouldn't even call it that. They bought out Tweetie and made that their official client, then proceed to make it a pain in the ass for all other Twitter apps.
The flow of OAuth on mobile is not nearly as bad when the app opens Safari to the OAuth screen, and when the user hits accept/reject they get sent to a URI like myappname://oauth which the iPhone app can register to mean relaunch the app
Twitter has shown quite a lack of taste in recent months (e.g. dickbar). I wouldn’t be surprised if they simply hadn’t thought about these issues, and that it’s not a sinister plan to further encourage use of the official Twitter apps.
Browser-based OAuth flow (like Facebook's new iOS SDK -- the one that avoids using embedded webview) has two advantages:
1.) Single sign on. If you're already logged in to the site in the browser, you don't have to enter your user/password again. Also, if you don't trust the app invoking the web browser, you can always exit the app and pre-login to site with the web browser before running the app again.
2.) Optional interstitial pages. Sometimes, your account may be accessed from some questionable location. The OAuth flow enables challenging users with additional security questions before giving authorization to the app (e.g. Facebook's identify-your-friends'-faces challenge, enter-your-birthday challenge, etc.)
Wow. I guess I'll be shutting down my feature-phone twitter client because of it. It's been in life-support mode for about a year, but I guess that's the end of it.
Decisions like this are making it clear that Twitter no longer cares about third-party clients. That they didn't even consider (that, or they just didn't care) that two weeks notice wouldn't be enough for many devs to make the change and get it through App Store approval is quite telling.
It's not the technical difficulty of implementing that's a barrier. It's the clear "fuck off" signals Twitter has been sending.
Isn't Facebook doing the same thing? In fact, I just got an email from them today that they're forcing the issue and all devs must adopt oAuth by September.
Yes! I'm glad finally someone like Gruber shared his opinion on this. Integrating Twitter in native apps has been a huge pain for me and trying to explain clients why they can't have a native branded user/password dialog in the app (like "all" the other apps) is really tedious. For such a big player like Twitter they made it really cumbersome for 3rd partys to do simple tasks like posting a tweet.
The type of token isn't what at's issue here, it's the method of obtaining one. OAuth 2.0 doesn't make a distinction between bearer and HMAC tokens during the authori[s]ation phase, which is what this article and discussion is about.
By the by, bearer tokens over SSL are not a great option given the lax enforcement of SSL policy by many actors in the domain. HMAC tokens provide a much higher level of security (and, contrary to your implication, are specified alongside bearer tokens with the OAuth 2.0 specification).
I'm designing a Twitter desktop client from the ground-up with Oauth. It is annoyingly over-complexified but doable. I suppose I can take a grim pleasure that others will have to suffer with me...
The biggest issue with Twitter oAuth sign-in that we have faced as developers is that the Twitter sign-in page does not work at all or is not optimized for feature phones with smaller screens and not running Webkit based browser. Always wished that Twitter provided a URL - twitter.com/appname that users could go to and assign all permissions and got a simple key + PIN that they could enter in our app to access their tweets.
What if Twitter decides to start putting ads for its own native clients on the OAuth screen? Given recent history, is there any reason this would be a surprise?
The point is that this is an illusion. If the native app puts up an in app browser (which is a very common strategy), then they have access to everything you type. They can query the page for that same username and password, they can simulate clicks, they can do whatever they want. And additionally, for all you know, its not even the real page you are seeing. OAuth security only makes sense on the web.
An in-app browser isn't the only way to provide OAuth, on most platforms you can invoke a URL and the browser application will open on the phone.
For example, on iPhone you can invoke an HTTP(s) URL, your app will exit, mobile safari opens, and you can then login and know that what you are typing is as secure as the OS/app sandboxing is....take a look at how the Facebook iPhone SDK flow works, its actually quite nice and very easy for users.
In reality, if you want to know that you aren't giving your username/password to a malicious third party, as an end user, you have to deal with a little inconvenience...being redirected in your browser to an SSL page that you trust, for example.
If the "third party" is actually a malicious native application, they can just simulate the launch of Safari, and most users probably won't even notice.
In this threat model, OAuth is practically a security no-op and a huge usability negative.
You're wrong. If the app developer is actually malicious this is true, but there are some non-malicious applications i just don't trust. Look at Sony, they're not malicious (e.g. they wouldn't record my password when they're not supposed to) but i don't trust them with my passwords (for obvious reasons).
I trust the intent of many app developers, I just don't trust their competence to store my credentials securely. So OAuth still requires me to trust their intent, but does solve the problem of competence (as long as I trust them to implement OAuth properly which can also be an issue).
And that's exactly what xAuth is. It just drops the pretense that oAuth inside a developer-controlled webview is trusted, authenticates directly using email/password, and then stores a token like oAuth.
When implemented using a contained web view I agree, it's not terribly useful and arguably even harmful. However if the user is directed through the real browser then they can clearly see where they are logging in and doing the authorisation. This is partly just a problem with iOS and it's limited ability to flow and pass data between apps than OAuth per se.
OAuth is storing credentials, it's just an access token rather than a password. The end result is the same - they have access to your account until you revoke it, either by canceling the token (OAuth) or changing password (non-OAuth).
Clients using xAuth don't store username/password, anyways. They just use it once to request a token, every future request is just like normal OAuth.
> it's just an access token rather than a password. The end result is the same
No, its dramatically different. If someone has my password then they have full authority over my account right up to and including changing the password itself. If they have an OAuth token they have whatever limited rights I granted to the token (could be read only, or limited to a subset of data, or automatically expiring after 24 hours).
The analogy that is often used is the special set of valet keys that come with some cars. They allow someone to drive the car - but no faster than 20mph, cannot use stereo, etc. etc.
OAuth 2 is way less cumbersome than OAuth 1.0a. Switching from username/pass to OAuth 2 would have been far less a PITA than switching to 1.0a where you have to encrypt/sign the requests by hand.
I'm not giving my username and password to my online accounts to random native or web apps when the service in online account in question provides oAuth.
My browser is already signed in to twitter/identica/whatever page is being requested. If the login page appears at all, it means the app is doing something shady.
By not using iOS. Other mobile operating systems can run more than one application at once, allowing the OAuth sequence to open in a browser you control.
iOS can do this too. But most developers use in-app web views to try and make it slightly nicer for their users. It's too late to demand that oAuth always go to the native browser. You use oAuth apps, chances are you're using an embedded view that you're taking on trust.
Btw, I have a popular WP7 app which uses xauth, primarily because Twitter's login screen is broken on the Windows Phone browser.