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.