So far we have discussed terminology and have looked at a brief overview of the events involved in OAuth. The next three parts we will look at the setup, authorization process, and API calls. The initial event to OAuth is setup which involves the user and consumer registering with the service provider.
The setup aspect of OAuth is often assumed and therefore overlooked because it seems rather trivial. However, doing so can obscure what is actually happening during the authorization process, and in consequence, during the making of API calls. So, let’s take a look at what the authorization process will assume has already been taken care of.
1. User and Consumer Registration
First, the user (resource owner) needs to be registered with the service provider. That is, they must have an account with a username and password. It is implied that the user has protected resources such as photos, files, or other information at the service provider. Why would a service provider exist if its users didn’t have any information with them? Second, the consumer that is wanting to use the protected resources of that user must be registered with the service provider as well. That is, they must have a consumer key and consumer secret (client credentials). In sum, the following information is needed at setup:
- User’s username at the service provider
- User’s password at the service provider
- User’s protected resources at the service provider
- Consumer’s consumer key at the service provider
- Consumer’s consumer secret at the service provider
Using the above information we can complete the authorization process using the OAuth endpoints (which we will discuss next) and begin making API calls (accessing protected resources). Let’s put look at this information in a real example.
Let’s say I want to share my Flickr photos on Twitter. Then, Twitter is the service provider and Flickr is the consumer. The first OAuth event is that I register a Twitter account, @joeientry. I have a username and password and my protected resources are my tweets, tweeps, and messages, as well as the ability to tweet and send messages using my account. To tweet images with Flickr, Flickr must be registered with Twitter, so, Flickr will have a consumer key and consumer secret.
It should be noted that Flickr is both a consumer and a service provider. So, Flicker is a consumer to Facebook and Twitter and a service provider to Snapfish and Shutterfly. That can make things a bit confusing when understanding OAuth, so let’s continue to focus only on wanting to share my Flickr photos on Twitter. The only information needed at setup are the following items:
- My Twitter username (joeientry)
- My Twitter password (********)
- My Twitter protected resources (in this case, tweeting)
- Flickr’s Twitter consumer key (a random string)
- Flickr’s Twitter consumer secret (a random string)
Now, of course, not all parties know all of the above information which is what makes OAuth so secure. Twitter knows my username, my hashed password, has access to all my protected resources at Twitter, and knows Flickr’s consumer key and secret. I know my username, I am the only one who knows my plain text password, I have access to all my protected resources at Twitter, and I don’t know Flickr’s consumer key and secret. Flicker does not know my username or password, obviously it knows its consumer key and secret, and though it does not know anything about my protected resources at Twitter, it knows the end point for accessing them.
So, that’s the setup. Using the above information we can go on to the authorization process which we will discuss next.