I hadn’t encountered a service running Twitter’s OAuth beta until I checked out Airmailr. While the service itself is pretty cool, I think the exercise of going through the OAuth flow for the first time was pretty cool too. Not once did I even tell Airmailr what my username was, yet it still worked. Trippy, eh?

The Widget

Airmailr is an OSX Widget created by Nial Giacomelli (@NialGiacomelli) and Glynn Smith. It gives you the capability to browse your friends, replies, and DM timelines as well as perform searches and view user profiles. While the widget will leave most power users looking for more, it’s a decent alternative for those who want Twitter to unobtrusively run in the background.

OAuth

I hate to say that the OAuth experience transcended my experience with Airmailr, but it did. I’m not discrediting Airmailr, it’s just that the OAuth experience came at the same time. So, having said that, here’s what you can expect when using Twitter services and apps in the future.

Request Authentication

The first step the app will go through is to tell you that it needs you to authorize it. It’ll (hopefully) provide you a link to Twitter where you’ll need to sign in. You have two options for an app: deny or allow.

Tell Twitter that you want to grant access

This is where the magic happens. Once you click the allow button, you’ve told Twitter that you trust the app so it gets access to your API without you giving the app your password.

Return to the app and tell it to try again

Once you’ve authenticated the application, you can close your browser/tab and tell the app that you’ve given it access. At this point the app will try to access your account again. If you’ve allowed access, you’ll be able to use the service without interruption. Even though the process is different and new to most people, it’s a step in the right direction.

View your “connections”

If you want to see who you’ve given access to or revoke access, check out the connections tab in your settings.

Earlier this week Alex Payne (@al3x), Twitter’s API lead, announced that Twitter’s OAuth beta is now open to all developers. This has been long awaited by many Twitter users and developers looking for a more secure way to start using third party tools.

Shortly after the announcement, Tipjoy was quick to announce their implementation and to date continues to be the only third party application, that we have noticed, to roll their implementation of OAuth.

The authorization screen looks similar to what Facebook has implemented for their applications. Click Allow and you’ll be on your way to integrated TipJoy goodness.

Twitter Launches Application Platform to Verify “Legit” Apps

While updating my account to enable TipJoy, I also noticed Twitter is silently rolling out their own application directory which they are calling the “Developer Beta of the Twitter Application Platform“.

From the Twitter Application Platform page developers can edit their registration settings for their application. The webform features a number of fields including space for application icons, indicating application type (client or browser) and access type (read-only or read/write).

After signing up with a registered application, such as TipJoy, the application will also appear under the user profile settings under Connections.

This is a great step forward for Twitter in building upon their early successes. While OAuth may not be the silver bullet, it can provide an additional layer of security around Twitter profiles. Also, with Twitter formalizing their process and creating an application directory (think iTunes), they will help reassure users that the applications are legitimate.

Recent events have pulled Twitter’s authentication methods even further into the limelight. People are becoming increasingly concerned about the safety of their profile and everything associated with it. What’s Twitter going to do about it, and when?

Twitter is working on a beta release of OAuth

Engineer/API Lead Alex Payne commented on the Twitter Development Talk group that the User Experience team is putting the finishing touches on a beta release of an OAuth implementation. This comment was made in November and mentioned a release toward the end of December. Since then, Payne has also said they (Twitter) will be experimenting with it after the first of the year.

The next full release of the API will be by OAuth authentication only

That only makes logical sense, right? After all, you have to eliminate all the weakest links to make a stronger chain. Also, using OAuth will decouple API rights from the general access rights used on the web. In turn, you’ll see more granularity of access control using OAuth, which is something BasicAuth sucks at.

Unintended Consequences of Better Security

For starters, OAuth is much more difficult for third-party developers to implement than BasicAuth is. It’s a new set of tools and technologies that most people aren’t really that familiar with. OAuth also entails bouncing around to the browser while authenticating, much like OpenID does. Once you allow your app once, you should be able to have it remember that and be fine on subsequent authentication attempts. However, it’s going to confuse a ton of people the first time. OAuth is not a security silver bullet, but is a step in the right direction. ( Payne’s words on OAuth )

Our Plea

Twitter: please don’t give up on this. We can’t stand to see it go the way of Track or IM. We desperately need to feel safe when using our credentials as recent events have given you a bit of a black eye. OAuth, OpenID, we don’t care – just make us feel warm and fuzzy inside.

Last week I wrote a post about OpenID on my personal site. There’s another authentication method similar to, but different from, OpenID called OAuth. OAuth stands for Open Authentication and was formed by a committee of users. The original spec for OAuth was released in late 2007. OpenID and OAuth were conceived for the same general purpose, but have little in common.

Imagine you own an expensive luxury car. A night on the town could put you at a fancy restaurant that offers valet service. Instead of giving the valet your owner’s key, you could hand the valet a less privileged key that would only start the car, allow it to be driven for one mile, and also lock out non-essential services (address book, navigation, etc). This is the basic concept of OAuth.

When you pass your username and password to an API, you’re giving it complete access to your account. If the wrong people get a hold of your credentials, they could use it maliciously and potentially lock you out of your account. Giving an API a password that only allows it to perform certain actions is the basis for OAuth and protects your identity from being used by others.

In the social networking world, FriendFeed allows services to interface with the API using a username and key that is separate from the password (Oauth in a nutshell). Other sites that tell you to use a secondary password or a key are operating under the same premise. Twitter also supports OAuth, but has little documentation on using it.

While OpenID mainly controls your information for websites as a whole, OAuth is primarily used for API access delegation. With OAuth, you can share information between websites without handing out your username and password. Neither one can (or should) be used mutually exclusive from the other service. Not all sites support OAuth, but it’s a growing trend that is catching steam.

Interested in a more in-depth analysis of OAuth? Check it out on Hueniverse.