Our group is going to be presenting this week, and we are looking at building on data sources that already exist, interfacing with them via their APIs.

Before we can use the APIs, we will have to prove to the system that we are interacting with that we have permission to use it. That’s where OAuth comes in.

Here’s how OAuth generally works:

picture alt

In short, the server wants to know that the user has given permission to the client to access their data, which is hosted the server. In order to assure the server that this is the case, the user asks the client to ask for that data on their behalf. The server then asks for the user to directly authenticate the request – to confirm that the client has the user’s permission to access their data. Once the user confirms, the server issues a “token” to the client, which is a pass to use the information in the future, and the client confirms to the user that permission has been granted.

There’s a longer, better written version of this here – I recommend that anyone wanting to know more about OAuth should read it.

The graphic above and explanation that went along with it made sense to me when I was thinking in terms of an app like Twitpic trying to access Twitter user data, but I was still having trouble understanding it in terms of API authorization. This graphic about the Google API helped.

picture alt

Most new APIs that use OAuth use OAuth 2.0, which was released in October 2012, but many older APIs still use the OAuth 1.0a specification.