Now, let’s look at the role that OAuth plays in access control. OAuth is an open standard protocol (RFC5849) that provides secure API authorization. That is, it is designed to help web applications control access to protected resources. Previously, we looked at terminology which is vital to understanding OAuth. Here we will put that terminology in context by taking an overview of the events involved with OAuth.
As a disclaimer, I will reiterate that one’s ability to understand OAuth will break down quickly if the terminology involved isn’t well understood. Unfortunately there is no standard terminology; even the terminology defined in the RFC are not frequently used. This tutorial will integrate terminology as used in the vernacular as well as the RFC by using the terminology defined in this tutorial as standard and including alternative definitions in parenthesis. Hopefully, this overview will solidify understanding of terminology and the general aspects involved with OAuth before looking at more specific aspects of OAuth later on. Be sure to read about terminology in the previous part, the Hueniverse section, and the RFC 5849.
As mentioned previously, OAuth deals with authorizing consumers to access a service provider’s protected resources for a given user (resource owner). There are a number of ways to provision access token credentials, but in this tutorial we will only look at redirection-based authorization over HTTP (see RFC 5849 Section 2). This means that the entire authorization process is communicated through a combination of URL redirects and XMLHttpRequest (XHR) requests sent over the HTTP or HTTPS protocol using the POST or GET method (there are others). The response will be in XML, JSON, or plain text. This also means that there will need to be what are called URL “end points.” These end points are where the requests are sent to or the browser client, such as Firefox or an iPhone WebView, is redirected to.
The goal of the authorization process is for a user to let one website application access the user’s information or resources of another website application. In OAuth lingo, the goal of the authorization process is for a consumer to obtain access tokens (the access token and access token secret) from a service provider which can be kept and used over time to access the user’s protected resources. OAuth involves involves five ordered events:
- User and Consumer Registration
- Request Token Request
- User Authorization
- Access Token Request
- Resource Request
The initial event can be considered the setup. It involves the user to creating an account with the service provider and the consumer obtaining a consumer key and consumer secret. The next three events can be considered the actual authorization process. First, the consumer must obtain request tokens from the service provider that are used to authenticate the consumer and identify the process in the next two steps. Then the user is redirected to a page hosted by the service provider where the “allow” button is clicked. Finally, an XHR request is made to exchange the request tokens for access tokens. The last step is where everyone wants to get to and is commonly understood as making an API call (resource request). Resource requests (API calls) are made as XHR requests and are what accesses the protected resources.
The next few parts will involve explaining in more detail what these events are. The OAuth process can be thought of like a digital handshake, or as Hueniverse says, the use of valet keys for the web. In any case, hopefully thinking of OAuth in terms of these five events will help keep perspective as we delve deeper into OAuth.