@twitterapi's countdown to Basic Auth removal | Hacker News Reader

@twitterapi's countdown to Basic Auth removal

countdowntooauth.com

16 pointstwapi25 comments

I think it's a huge mistake. Mainly because when I write some random application (bot or something) I really don't want to mess with oauth when I just want to send a tweet. Plain.

Please, twitter. Don't.

This is a great move for Twitter.

If Twitter's going to be a serious platform, it needs to stop requiring me to hand my password to every Tom, Dick, and Harry app that I want to try out. That's what oAuth accomplishes.

The point was to encourage users to only use oauth. They could allow basic auth only on a conscious opt-in process by the user (assume that I want to write a bot that sends DM to my users, I don't want to mess with oauth just when I can drop my twitter password in the curl code, but I can log in to the twitter website to enable basic auth in this case).

I really see the point of using oauth for almost any web-based apps, and now also for desktop-based ones. Adium does it pretty well (but one day the twitter support broke and I've been using Tweetie/Echofon since then). But it's still about access complexity: big apps have still months to rework functionality using basic auth, but in some cases, oauth is just hellish.

I repeat myself, yes. Please: opt-in, twitter, we need it.

This comment sounds really assholish. I apologize in advance.

This is why libraries exist. You shouldn't be implementing OAuth yourself.

UX, not libraries seems to be the bigger barrier for OAuth.

Isn't the UX really straightforward for this by now? It's a "log in with Twitter" button. That's it.

Was thinking more for Mobile / Desktop apps, but I see that xAuth support is fully out which should streamline things

http://twitter.com/twitterapi/status/9702051031

And importing a new library into my codebase is a non-trivial activity. I need to vet it, ensure it will be supported and updated, and that well, it actually works. It makes Twitter implementation from "pretty much trivial in any language/device under the sun" into "Pain in the ass".

I don't mind supporting new APIs when they offer a solution to a real problem. As I've asked in my other comment, how many people have really lost their credentials via basic auth?

Edit: I can't seem to reply to steveklabnik's post below, so I do it inline by emphasising importing a new library is a non-trivial activity. I'm afraid that mass importing of external code into my projects is not something I undertake lightly; unless it's a platform supported (or very widely used) library, it requires a reasonable amount of vetting to ensure that it a) Works b) Does't break anything else c) will continue to work in the future.

My question remains: Why? What is the insanely pressing need to move to OAuth when users don't really seem to care and I can't find any evidence that it's been a real security problem? I completely agree that it's nicer in theory, but as mentioned in my other post, I don't actually see that it's any more secure. Unless I'm being highly dense, it would fall to a completely trivial quazi-social engineering hack in almost all end user cases.

Have you actually done an OAuth integration yet? It could just be that I happened upon great support, but adding it to an app was just "require this library, update a config option, add a different link here and there." It was half a dozen steps, tops.

And OAuth is a solution to a real problem. I don't want to provide my username/password to people who aren't Twitter.

To reply to your edit, which is strange... I can see the "reply" link to myself.

I guess we have different opinions on libraries. I come primarily from Ruby, where testing is heavily emphasized. I don't mind adding stuff to my app because I'm constantly testing it against things breaking. In addition, most libraries come with their own tests, so I can verify for myself that libraries work.

The whole reason I use libraries is that they're a black box. I shouldn't have to worry if the library is broken or not, because they should be working. Maybe I've only used high quality libraries, but I can't remember the last time I came across a library bug.

Anyway, I don't have any stats to back things up, but users do care. "Login via Twitter" is so much nicer than "put in your twitter name and password." I'd be very hesitant to do the second, but not the first.

I come from the end of the universe furthest from Ruby.

If I had access to a library, I'd use it. Now I have to go find one, port it, debug it, test it, review it, and deploy it.

Or drop the feature.

And if I have to go through the whole process here, I'm going to look at competing communications platforms, too.

And as many folks have found, forcing an update or a port means some applications will be ported off your platform, too.

This change within Twitter will derail at least some of those environments.

What does your one-liner OAuth implementation for wget in bash look like?

Because that's what it's competing with, with Basic Authentication. A simple POST to statuses/update.xml with HTTP username and password, a wget one-liner.

I just said it was easy, not that it'd be one line. But most of the libraries I've seen are pretty simple, see the oauth gem: http://oauth.rubyforge.org/

Three or four lines. Not the end of the world.

I agree that it's not as easy and simple as HTTP Authentication, but it's much nicer from a user's standpoint.

Why not implement OAuth yourself? It is pretty straightforward. There aren't really any edge cases to handle.

I would if I had to, but I don't like re-inventing the wheel. Especially if the wheel is pretty straightforward... I'd rather let someone else do the work.

There are options besides breaking all the existing code. Rate limit the basic API more or create an option to allow it per account. So many old apps will just be abandoned now.

You can switch to xAuth, if you don't want to mess with oauth.

It's somewhere in the middle between basic and o

http://dev.twitter.com/pages/auth#browser-less-apps

Using something like http://github.com/mbleigh/twitter-auth is actually easier than setting up a twitter app to use basic auth, imo.

Edit: OK, I was wrong, as I'd hoped - you don't need a web browser. The rest of my post stands unchanged as, regardless of my interpretation, it kills the Twitter support I just wrote in less than an hour into one of my apps, and renders it a multi-hour (if not day) redevelopment. I'll probably just kill the feature.

This seems like a silly move: What was previously a very easy to target platform is now much less easy. Was there a glut of user credential theft from the basic authentication API that's caused this? Or is it the architectural purists winning out over engineering pragmatism?

I'm not convinced that, on most devices, it will actually add any security anyway. Consider iPhone application "EvilTwitter". User enables Twitter support. I, evil developer, present a fake Twitter OAuth page. This looks identical to the Twitter login page, carefully configured to hide most of the Safari interface (as 99% of iPhone Safari embedders do). The user enters their details, I steal them, the present a "Woops, wrong password" error. I redirect them to the real OAuth verification page. From here on, my application works fine - the user just assumes they mistyped their details the first time (as mobile device users do, well, continuously).

Subscribe to the Twitter developer lists. They have solutions for platforms without a browser.

OK, having researched, I presume you're refering to the XAuth stuff http://dev.twitter.com/pages/auth#browser-less-apps.

How the frell is this any better than Basic auth for most users? I can only see that 1) I don't have to store their password on my client and 2) it won't be sent across the network plaintext.

This is useless. End users have no idea that I'm actually doing 1), and 2) has never been a problem (HTTPS supports Basic auth fine for transport encryption).

My experience with open source Ruby solutions was mixed. It still is a vastly more complex problem than just being able to use my programming languages inbuilt http functionality.

Nope, you don't need a browser.

I've actually gone and removed Twitter support from an application I work on. It was a small, fun /tweet command in Mobile Colloquy. I wrote it on a whim; it came out to maybe 100 LOC (with proper error handling and formatting). More time spent in NSURL{Connection, Request}'s docs than on anything else.

It was removed because it isn't worth the hassle of adding in an {O, X, YetAnotherCharacter}Auth library. No, I don't have to write the code for it. No, including an entire library is not better than 100 lines of code (where the the authentication part amounts to one line if there isn't any error handling).

Twitter's API went from being incredibly nice and easy to work with to having a huge barrier in front of it as soon as they deprecated basic auth.

//edit: Note: I'm not trying to condemn OAuth. I'm sure it has its uses (even if I'm not quite sure what they are). I just don't see how it is a benefit in this particular case.

My twitter client app uses Basic Auth yet doesn't store username or password, it's all kept on client side. I won't be rewriting so it'll now be useless.

Reply on news.ycombinator.com