I know OAuth pretty well since I implemented a client a little over a year ago. It was hard work, but I got there, with help from one of the designers, Joseph Smarr. This version of OAuth, 1.0, worked something like Flickr's authentication system, which I had implemented a few years earlier. Wasn't sure what was gained with the new complexity, but Twitter had said pretty clearly they were moving to OAuth, and I was actively developing on Twitter, so I figured I'd better support it.

Since then there's a new OAuth that is incompatible with the one I implemented. I'm confused now about which one Twitter will use, but I don't care because in the interim I stopped developing Twitter apps. I've decided that when and if Twitter pulls the plug on non-OAuth apps, I'll just let my apps break.

The other day I had to write some OAuth code for another web app, and it was a bitch -- my Twitter-OAuth code didn't work with the new app. So we're in the place you don't want to be, with compatibility expressed in terms of apps instead of standards. It should be enough to support OAuth, but it's not.

The new OAuth is an attempt to simplify it, and if that's what we're doing, why not go all the way and make it Really Simple™ (sorry). Hey it's an open format, so anyone is allowed to have an opinion. So here goes.

Imho FriendFeed had a good idea. Instead of giving an app your password, you give it your remote key -- a random string they generate for you. So now you've authorized apps to access your account without giving them your password. No protocol change, we're still using Basic Authentication. The user's life gets a little more difficult, but so little it's hardly worth mentioning. They just have to understand this idea of a remote key. And it stays truly simple for developers.

But that's not as good as OAuth because it doesn't allow the user to selectively turn off one app while leaving the other apps alone. (Note that you always had the power to turn off all the apps, just change your password, and boom none of them can get into your account.)

Credit card companies have had a solution to this for a long time. Consumerist has an excellent survey of the field. Each bank calls them something different, but they're all the same idea. CitiBank calls them virtual account numbers. They're credit cards that are good only at a single merchant. If you don't like what that merchant is doing you can just terminate the virtual account and they stop misbehaving right away, leaving all your other online accounts alone. All the virtual accounts funnel into the same account you've always used, but you can do business without giving away that account number. Now when someone steals your identity, they've got nothing. Isn't this exactly what we want from authentication? And it can be implemented without creating any new hurdles for developers.

Credit card companies use these numbers to protect their money, so why isn't it good enough for us to protect our users' identity?

 5/8/2010; 10:38:53 AM.   .