Web services are offered by many top sites (including Twitter, Facebook, and Elgg-powered Sites) to allow third-party access to that site's data. Developers can then use the data on their own sites through display widgets, aggregate readers, or however else they want. Most of the time this data should be accessed securely, requiring some type of API authorization check.

When it comes to API authorization one protocol jumps to the forefront: OAuth. Both Twitter and Facebook have implemented their API calls to use this token-based model. The system requires two keys: a public key which is sent to identify your request, and a private one which is used to encode a message digest to guarantee the request is secure.

Confusion enters into the mix when you consider authentication: signing a user in using an external account. Again, Twitter and Facebook rely upon OAuth. However, an argument can be raised that OAuth is intended solely for authorization, not authentication. OpenID is one of the leading tools to help with this. Rather than having multiple accounts across each of the sites you visit, you could have a single OpenID account which is shared among all of the accounts. The concept here is to allow a single sign-on event. Visiting other OpenID-enabled sites would allow you to login with a single button click validating back to your OpenID account.

OAuth and OpenID are just two potential tools available to developers looking to expand their site with web services. Though some argue there's too small a distinction between authorization and authentication, others liken the difference to the logic-presentation separation of MVC architecture. Ultimately it's up to you to decide how best to use one, the other, or both. We'd love to hear what you think!