Rethinking authentication

Monday, January 05, 2009 by Dave Winer.

First a caveat, this is going to be a technical post, so if you're not interested in techie stuff, you can skip it. However, I'm going to try to make it understandable to smart users who are willing to scratch their heads and read it two or three times, if you care to. 

There's been a persistent problem in the twittersphere when developers have wanted to enhance the service but require access to the user's account. There's no other way than to ask for the user's login info: their username and password. If the developer is ethical, this is not a problem, it's much like giving credit card information to a vendor. But you can get in trouble when the developer isn't trustworthy and uses your information in malicious ways. We got a taste of this, this weekend. 

Immediately people in the know say Use OAuth! -- believing that will solve the problem. I understand OAuth, I've implemented Flickr's authentication system which was the inspiration for OAuth. It's a complicated dance for the app developer, but it provides the user with an important ability that's supposedly available no other way. The user can de-authorize one app without de-authorizing all others. It's true, you can do this with OAuth, but it's not the only way to do it, and it's more complicated for users and developers than the other way, which I'm now going to explain. 

I got this idea when Twitter rate-limited me yesterday. I was debugging some code, and I guess I made more than 100 calls in an hour. Now I can't make any more calls from my LAN (even though it's been almost 24 hours since the offense). This showed me one very important thing -- Twitter has the ability to block calls by IP address. That's the key.  

Okay, so now assume I've given my username/password to Wimpy's App Shop, who has a neat little Twitter add-on gizmo that I love, and everything's going great until one day Wimpy, whose shop is suffering in the recession, decides to make a little extra money by selling my login to Bluto's Greasy Spoon Spamporium, who proceeds to send huge numbers of phishing messages to Chris Brogan, Kevin Marks, Chris Messina and Guy Kawasaki. This is very annoying. We must stop it at once! 

Now imagine that Twitter had a page that showed all the IP addresses that have used your login in the last 30 days, with a start date for each and a count of calls made. I bet you could figure out which one was The Greasy Spoon Group, pronto. Further suppose there was a checkbox next to each IP address. You could uncheck that one, click Submit, and voila, no more spam from your account. You just did everything that OAuth promises to let you do, and no one had to implement the dance. It worked with today's simple and klunky worse-is-better authentication system. 

Now IP addresses are ugly and not informative, so add a little enhancement, and have Twitter do a reverse DNS lookup for each one. If something simple came back, like appshop.com and not adsl-86-229-2-19.dsl.pltn90.sbcglobal.net, display it instead of the IP address. Now it would be even easier to spot the nasty dude.  

That's it, that's the idea. I think this works -- do you see any problems?? 

Update: Great comments. Over on the Twitter blog, Biz says they're going to release a closed beta of OAuth this month.