RAAK

Last week I went on about APIs. This week we move on.

When working with APIs, the first hurdle that almost everyone trips up on, is OAuth. Everything after that is easy.

So what is OAuth, and why does it have to stand in the way between us and API bliss?

Let’s start with a more fundamental question. What is authentication?

Who are you?

Let’s demonstrate authentication using typical Cryptographic Role-playing:

Alice has to prove to Bob that she is indeed Alice, before Bob starts sharing things with Alice that he might not want to, or be allowed to, share with anyone else. Alice and Bob thus enter into private conversation with each other.

Authentication is so deeply ingrained in our everyday lives, that we have completely forgotten about its existence. Another reason we don’t think about it is that our minds are so good at authenticating people visually, that we don’t even know that we do it all the time.

Think about it. How much thought do you put into recognising your work colleagues each morning before you start talking about sensitive project information with them?

Who’s given you the right?

Why is Authentication not enough? What is Authorisation?

Charlie has to prove to Bob that Alice has given him permission to speak to Bob about things that only Alice and Bob normally speak about. Charlie is thus included in the private conversation between Alice and Bob.

With the rise of Social Networks, and indeed Social Network APIs, the need for an authorised third party arose. Why?

Social Networks are all about sharing stuff. Now, the first layer of sharing is within the Social Network itself, with other members of your Social graph. However, that’s not where the sharing stops.

The real magic behind Social Sharing is that the things you share can travel with you, to other websites and Social Networks. It’s also about things you do outside of your Social Network, to make their way back into your Social graph.

It’s about your Instagram photos making their way to your Facebook friends, and it’s about listening to new music your friends discovered in Spotify.

Authorisation is necessary – to share your information shared on one social network with another entity, and to specify exactly which information to share with that entity.

OAuth

This is where OAuth comes into play.

The OAuth protocol was first drafted by Twitter, with Google joining them soon after. After that, it was handed over to the IETF for proper standardisation.

OAuth allows websites to let a user log into their social networks and grant the website certain permissions, without having access to the user’s Username and Password.

How does this happen?

1. The website redirects the user to a special Authentication and Authorisation URL, hosted by the Social Network. It sends a few parameters along as part of the URL, which tells the Social Network exactly which data they want to access
2. The user logs into their social network (if they’re not already logged in)
3. The user gets shown which of their data the website will be able to access, and agrees to it, or denies the access
4. If the user agreed in step 3, they get redirected to the website, with a random number (called an Access Token)as part of the URL. The website then presents the Access Token to the Social Network to get access to the data they want

The Access Token is the proof the Social Network (Bob) requires to know that the user (Alice) has given the website (Charlie) permission to access her data.

So, while OAuth might not always be very simple the first time you use it (especially not OAuth 1.0), it provides a very powerful service, which we tend to take for granted. It might not be perfect, in the same way that no Security is perfect, but it gets the job done.

Considering all of this, it’s actually very simple, and very effective.