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.
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.
Hardly a "shit sandwich".