Twitter’s Shit Sandwich

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).

The browser chrome is just a handful of native controls the developer could drop into his own views in less than an hour.

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...

For tech people it is not seamless,

For non-tech people it is worse than 'not seamless', it is entirely confusing.

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.

His point is that the interface is a usability loss, and a big one.

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.

The third party must story my password in plain text (yes. it could store it encrypted, but it must be able to decrypt it, so an attacker could too).

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?

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.

It's not the technical difficulty of implementing that's a barrier. It's the clear "fuck off" signals Twitter has been sending.

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).

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.

http://stackoverflow.com/questions/4113934/how-is-oauth-2-di... <- this is a pretty nice summary